Bitcoin, is not suitable, for securities settlement.

I normally don't blog about technologies or systems which I have not personally designed and involved in the development ,and hence have an in-depth understanding, so if anything in this blog is not technically accurate, please contact me and I will correct.
Here goes..

I keep hearing that "blockchain" and other distributed consensus technology can revolutionise the payments, clearing and settlement infrastructure of the financial system and that, no, the existing bitcoin blockchain just won’t do. (which suits bankers fine, as few were ever anything  to gain from bitcoin the world’s most popular crypto currency, outside of the control of any bank).

Then enter the marketing and media guys and almost every day, there is yet another committee, seminar, or incubator announcement, using the bitcoin blockchain?


What’s going on!?
 My conclusion is that most of the people discussing bitcoin haven’t actually looked under the hood, and have very little knowledge about how bitcoin actually works. It reminds me of the whole "Digital Signature" exercise all over again, people with vested interests push technologies they don't understand.

 I've also noticed that enthusiasm for bitcoin tends to be inversely related to one’s understanding of it, and of course that famous "white paper" by yes an faceless, anonymous person, so lets start there.

A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they’ll generate the longest chain and outpace attackers.

Hmm a system in which anonymous, programmers and crypto geeks are required to always act honestly for the sole good of the bitcoin community. Yep in the sense of securities settlement it is all built on a house of cards, but lets dig a bit deeper, so we can understand why..

It has been known for a long time, at least two decades from my memory, that cryptographic signatures and public keys can be chain-linked to form a set of unforgeable records (its known as a X.509 certificate chain, and in use by almost everyone daily via SSL)).  This same cryptographic chain of signatures can be applied to any records or set of transactions for, say, digital cash (or any ledger record for that matter). Counterfeiting ledger assets is impossible, and theft or misappropriation cannot happen without gaining access to the asset owner’s private key.

If I give you crypto-proof that some asset belongs to me and that I just transferred it to you, you have no way of knowing that I haven’t already done that with someone else, unless we can both refer to a definitive ledger of timestamped and crypto-signed transactions. Let’s say this ledger is maintained and hosted by some trusted third-party. The third-party cannot forge any ledger entries, as each entry is signed by each party, so what’s the problem with this setup?

There are three problems:

• The third party could delete a transaction, reversing history
• The third party could censor a transaction, refuse to enter it into the ledger
• The third party could forge a transaction, create or alter a transaction.

And it’s not just the third party itself who has this power, it’s also the government who regulates the third party, or the hacker who infiltrates the third party. For bitcoin, using a trusted third party for this task loses some of the “main benefits” of the crypto framework as real world third parties have a real-world identity (a registered business, an IP address, etc) and if known, these third parties can be censored by governments, shut-down, fined or imprisoned. One of the key design goals behind bitcoin is censorship resistant digital cash.

First, bitcoin is a peer-to-peer network. It is architecturally decentralised or P2P, it is not distributed (it seems like no-one has actually read, or understands, Paul Baran 1964 paper) . It is a fact that there is no single "bitcoin server" where those chain-linked blocks of transactions (transactions that are themselves also chain-linked via crypto signature) are stored. Instead, the transaction record is stored (well distributed, replicated) across all of the P2P nodes on the network. There is still only a "single" bitcoin block chain in existence, which is a shared resource of the P2P network. Over an extended period of time, currently about six block counts from any transaction. Anyone can be a node on the P2P network anonymously. This is what’s meant when people say that bitcoin is a “permission-less” network. This single blockchain resource "replicated"across potentially an unlimited number of P2P nodes is also an architecture defect, what is required for any scalable solution is a fully distributed architecture, just like the internet, where "data and processing" is fully distributed; but lets leave this discussion for another day..

Most people understand a timestamp to mean something generated by an accurate clock. But this, is a peer-to-peer network, so it doesn't have a "clock". The nodes on the network have clocks, but since these nodes could be anyone, you can hardly trust the timestamp of any given node. So how does exactly does the bitcoin network “timestamp transactions”?

What bitcoin means by ‘timestamp’ is in fact the ordering of blocks of transactions. This block of transactions came immediately after that block of transactions. It is in this sense that the “network timestamps transactions”. And it does this in a very cleaver way, “by hashing them into an ongoing chain of hash-based proof-of-work.”

This is the point where many people get lost. Before moving on, lets trash all mention of any link between bitcoin and Gold mining they are simply not relevant concepts within bitcoin and simply trend the discussion down rat holes. Done...lets move on..

The basics are quite simple, we just need to first agree a few concepts firstly. A “hash-based proof-of-work” is a solution to a problem, a hash problem. The “hash” refers to a branch of mathematical functions called “cryptographic hash functions”. They have a neat feature that whatever data you put into one of these functions, they effectively return a pseudo-random number of the same bit size. You can’t really predict what value the function will return given a certain input, without actually computing the function. Between inputs and outputs, there is no easily predictable correlation or pattern, The SHA256 bit function chosen by bitcoin is good at this, sometime simply watch the outputs change, a single bit input change will typically produce a full 256 bit output change, very cool... I digress, sometimes technology is just cool.

In bitcoin the hash problem is like “input into the hash function a (1) bunch of transactions along with (2) the hash of the previous block of transactions and (3) an arbitrary number N; if the hash function returns a value below some number D, problem solved, if not, increment N and repeat.” There’s no way to solve this problem except through iteration. So you set your computer to the background task of running billions of hash computations until it solves the hash problem. No rocket science here...

And that’s why it’s called “proof-of-work”. The problem is hard to solve, it requires work (consuming MIPS, and electricity). But once it’s solved, you can prove to someone else that you did the work to solve it. Just show them the data (a bunch of transactions plus the hash of the last block) and that winning number N and let them calculate the hash. If the hash value is the same below-D number that you say it is, they have proved that you solved the problem. The problem is hard-to-solve but the solution is easy for others to verify.

So this is how the bitcoin network timestamps transactions. The nodes on the network (“miners”) , actually "hashers", but not nearly as cool a name, collect transactions that bitcoin senders broadcast and each hasher, works at solving the hash problem over a set of transactions. Whenever a node solves the hash problem, it broadcasts the block of transactions along with the proof-of-work. The other nodes verify the work and start hashing on top of that block (i.e., including its hash in the input of the hash problem).

And this is what bitcoin means by “forming a record that cannot be changed without redoing the proof-of-work.” Nodes on the network build on top of the “longest chain” of blocks. If an attacker wanted to reverse the history, say, 5 blocks back, he would have to redo the proof-of-work of those 5 blocks before other nodes would start accepting that his version of history is the version (because it’s the longest chain). And that’s no mean feat. We will simply forget the issues with forks and how a single blockchain is generated, also a separate topic sometime, but for now a single blockchain is being built, typically 6 blocks ahead of an actually confirmed transaction..

This is a neat result. If every node follows the rule that the chain-linked set of blocks with the most work behind it is the blockchain, then every node’s local copy of the blockchain will be exactly the same. And if an attacker wished to maliciously replace part of the “sequence of events witnessed” by the network (eg, one where he made a big payment to someone) with an alternative version of history (eg, one where he didn't make that payment), he would have to redo the latest work of the longest chain, and do this work at a faster rate than the rest of the network combined. Hence, he needs to control in excess of 30% of the network’s total MIPS power. Of coucs there is an obvious defect in the above logic, as the block chain must grow, it becomes computationally infeasible (time taken) for any independent observer to actually download its own copy of the "total" block chain and verify all of the blocks and transactions from the "genesis" block, to the current transaction, but also a topic for another day.. let stick to the main thread of this blog..

And that, in a nutshell, is bitcoin’s security guarantee. If you’re comfortable believing that an attacker is unlikely to ever pull together more than a third of the network’s total computing power, you can trust in the blockchain’s record of transactions. Unlike with the case of a database hosted by a third-party, there’s no easy way for record entries to get “deleted” from the blockchain. As you can see there is no fancy maths behind the security of bitcoin at all. The only reason that a cryptographic hash function is used is that a hash-based proof-of-work problem has the property of being hard-to-solve-but-easy-to-verify. Any function which has asymmetry in solution/proof would do just as well. Without this asymmetry the network would grind to a halt if everyone had to redo everyone else’s work. But with a hash problem you can easily prove that you did the computational work to solve it, even though the solution is utterly useless maths. Hence it is now obvious that the the security behind proof-of-work is not “based on maths” at all.

If one takes nothing else from this blog, it should be that "bitcoin" is NOT backed by maths...

This is an economic model of security, not a cryptographic one. Proof-of-work requires an attacker to make a substantial capital outlay to have any chance of pulling it off. You have to buy the computing MIPS, pay the electric bill ect. In fact today, bitcoin mining is in more like a computing oligarchy than a computing democracy.  Sorry.. bitcoin "hashing", there is absolutely no Gold anywhere in bitcoin.

In bitcoin you have no way of authenticating the real-world identity of any node, this allows a single attacker to masquerade as a bunch of different identities and gain control of the network, no-one can tell whether 1000 nodes are really 1000 different people/entities or just one guy behind them all pulling the strings. Computing power alone equals voting rights in bitcoin. Now in the original bitcoin world, authentication wasn't an option, because if the real identities of the nodes are known to all, governments or criminals could compel those nodes to censor transactions and KYC/AML transaction senders.. or just criminalise the whole thing and arrest the operators behind the nodes.

Hence the bitcoin protocol is not only architecturally decentralised, it is also politically decentralised. The network has no gatekeepers, you don’t need permission to join. The only admission criterion to contributing to the network’s consensus is access to computational power. One could discuss the whole concept of the  Global "decentralised collaborative organisation" which bitcoin has effectively created, yes there lots of cool "social engineering" stuff within bitcoin, but also a topic for a another day.

As long as a majority of CPU MIPS power is controlled by nodes that are not cooperating to attack the bitcoin network, they’ll generate the longest chain and outpace all attackers.” But if an attacker has access to more than 30% of the network’s computing power, all bets are off!.

As at May 5, 2015, there were four major bitcoin pools each controlling at least 10% of the mining mining power. Together, they control 58% of the mining power. That means that if the four individuals operating these pools decided to work together, they could rewrite the bitcoin blockchain! And this assumes that each address is an independent group, which may not be a factual assumption.

Note there are some alternative to bitcoin systems proposing a "proof-of-stake" and slight modifications to this, as an alternative to "hashing power, but these all have the same underlying issue, its simply a matter of the point they all become "centralised".

Hence we are back at my opening remark, "bitcoin is a system in which the total security is based upon anonymous, programmers and crypto geeks, or anyone who has CPU MIPS, to always act honestly for the sole good of the bitcoin community".

The main protecting force of bitcoin today has been people's good will and lack of sophistication, and the fact that there is no real risk/reward in attacking the bitcoin mining network. We are still seeing the "early" adopter skewed rewards which still make mining disproportionally attractive. Some 80% of all mined bitcoins todate are still being hoarded. Where bitcoin value is "concentrated" and the rewards of a successful attack are higher, such as Mt Gox, millions were lost; bitcoins response, do nothing. I have seen posts where, the position is, any loss has nothing to do with bitcoin. Perhaps a valid comment for a group of crypto geeks, but not for mums and pops using bitcoin.
This is security 101, where risk is proportional to "one time loss",  threat source capability and probability of success. The greater than 30% of network computing power threat is actually directly related to the probability of success. Additionally the poor bitcoin tps is forcing lower block chain counts to confirm transactions, which increases this risk, as does the proposal to increase the bitcoin blockchain header size,and reduce the rate at which "hashing" is successfully.

If billions of dollars worth of securities are represented through meta protocols on the bitcoin blockchain, as some are eagerly trying to push..will result that attackers will have a way of constructing a scalable payoff for attacking the network. Acquiring a substantial portion of the network’s hashing power is not an insurmountable goal. What’s required is a sufficiently large monetary incentive to execute the attack. Putting billions of dollars worth of financial assets on the bitcoin blockchain materially changes an attacker’s incentives. Basically it increases the Risk of a loss. Managing risks is a fundamental part of any payment or securities exchange, they have teams of people that do nothing else, there is zero risk management within bitcoin.

As an example, in real world commercial applications, consider that many, single mainstream finance deals routinely outsize the entire market cap of all of the cryptocurrency currently in existence; this begs the question of how to properly incentivise transaction verification in the “trustless” model when a particular deal has more value than the entire market cap of the system.

Bitcoin transactions can then be reversed if the attacker is willing to make the capital outlay to acquire the hardware and expertise and pay the electricity bill required to pull it off (bribing a couple of large mining pools is probably the path of least resistance). For all we know, criminals may already be in the bitcoin mining community. If the attacker is successful, the attack in theory costs nothing, as the attacker collects the mining award of the blocks he solved that “replaced” the original transaction history, blocks that he made into a fork that is now the chain with the most work behind it.

It might seem crazy to the uninitiated that this “append-only” distributed ledger which is the bitcoin blockchain, by design, contains an avenue for deleting history. After all, everyone saw those blocks of transactions before they were overtaken by the attacker’s fork. Nobody will be fooled that the protocol’s “network timestamp” corresponds to the ordering of transactions that actually occurred. But that’s how the protocol works: the bitcoin blockchain is the chain of blocks with the most work behind it, this is bit coin voting in action. This is the price you pay for the censorship-resistant design.

Indeed, in the case of bitcoin, crypto-geekery offers nothing like an escape from the power dynamics within our society. One merely escapes to a different set of rules, not one controlled by ‘politicians’ or large corporates, but one in the hands of programmers and those in control of computing power. In fact there is no need for any real entity to be associated with any mining operation, it can simply be spawned MIPS based upon a set of "evolutionary" programming rules.

It is only when we think in these terms that we start to see bitcoin not as a realm ‘lacking the rules imposed by the state’, but as a realm imposing its own rules. It offers a form of protection, but guarantees nothing like ‘empowerment’ or ‘escape’. The concept of truly anonymous transactions are also not a fact within bitcoin.

When disassociated from the programmers who design them, trust-less MIPS based block chains floating above human affairs contains the spectre of "rule by algorithms".  end soapbox.


The Facts
To serve as a replacement for the legacy technology implementing book-entry assets, a distributed ledger of financial assets will have to ensure a tight correspondence between what the ledger and the law say is the state of who-owns-what. This is obviously incompatible with a protocol based on anonymous transaction validators; the law will not treat a ledger record as authoritative if everyone knows that the current longest chain contains blocks generated by an anonymous attacker who replaced a bit of history that was chronologically prior. But the bitcoin protocol has no mechanism for dealing with this scenario, no mechanism for bringing ledger state and legal state back into alignment. How could it…remember bitcoin’s design goal.

The financial system and its regulators go to great lengths to ensure that something called settlement finality takes place. There is a point in time in which a trade brings about the transfer of ownership–definitively. At some point settlement instructions are irrevocable and transactions are irreversible. This is a core design principle of the financial system because ambiguity about settlement finality is a systemic risk. Imagine if the line items of financial institution’s balance sheet were only probabilistic. You own X shares of Y with 97.5% probability. That is, effectively, what a proof-of-work based distributed ledger gives you. Except that you don’t know what the probabilities are because the attack vectors are based not on provable results from computers science but economic models. Do you want to build a settlement system on that premise?

Of course not. And you don’t have to because there are many ways to design distributed, shared ledgers, depending on your goals. And I’ll venture to guess that censorship resistant securities transactions is not the reason why financial institutions are looking at distributed consensus technologies. Their goals are rather different from bitcoins’s. Increased transparency is one, largely driven by the belief that regulators will grant concessions on capital charges for trades cleared through settlement systems that offer this. Efficiency through automating the back office is another. But probably the main goal is increasing the speed of trade settlement.

Now a few more facts, bitcoin is currently globally processing ~ 4.8 tps over the last six months I looked for this blog, and has a theoretical maximum of 7 tps. Yes this is less than 10 tps to run a global securities settlement system on, so why is there any discussion linking bitcoin and securities settlements? Do these proponents actually understand what they are suggesting, or is it the "dot com" boom/bust cycle all over again.?

Nothing in what I have said here is meant to take away from the inspired, solution that bitcoin implemented for censorship resistant digital cash. There is no reason why society should not have a digital cash that replicates the same anonymous and permission less properties that we already enjoy with physical currency, be it with higher risks. The point of this blog is to demonstrate why bitcoin is not suitable for assets with significant value and hence one time loss i.e Risk.. and in particular is not suitable to "anchor" any of these transactions, via abstraction.

The ongoing proposition that security interests and other property titles should also be cast in the same bearer asset needs to stop. Few actually want this, and, anyway, few jurisdictions will actually allow it. (In fact, it’s looking increasingly likely that few jurisdictions will even grant bitcoins bearer asset status.) This is not a serious idea.

If you are prepared to use trusted third parties for authentication of the counterparts to a transaction, I can see no compelling reason for not also requiring identity authentication of the transaction validators as well. By doing that, you can ditch the gross inefficiencies of proof-of-work solution that is not only tens of thousands of times more efficient, but also places a governance structure over the validators that is far more resistant to attackers than proof-of-work can ever be.

Scalability, Consensus and bitcoin blockchain stuff...
Scalability is now at the forefront of the technical discussion in the bitcoin scene, and it has not yet being used, in a "commercial" sense. This is one fundamental issue with all bitcoin derived or variants designs that needs to be addressed. Out of all of the various proof of work, proof of stake and reputational consensus-based blockchain designs that have been proposed, not a single one has managed to overcome the same core problem: that every single full node must process every single transaction. Having nodes that can process every transaction, even up to a level of thousands of transactions per second, is possible; centralized systems like Paypal, Mastercard and banking servers do it just fine. However, the problem is that it takes a large quantity of resources to set up such a server, and so there is no incentive for anyone except a few large businesses to do it. In bitcoin all of the resources are being focused on useless "hashing". Should this happen, then those few nodes are potentially vulnerable to profit motive and regulatory pressure, and may start making theoretically unauthorized changes to the state, like giving themselves free money. All other users, which are dependent on those centralized nodes for security, would have no way of proving that the block is invalid since they do not have the resources to process the entire block.
Additionally a simple analysis of these approaches will easily show they, they all deprecate to a "centralised" solution at some point, the concept of distributed consensus is an illusion, and cannot be relied upon to form the basis for any block chain security.

Risks
Below is just a quick set of risks, I considered after a couple of hour looking into bitcoin; these are not meant to be a definitive, or complete set of residual risks within bitcoin, they simply illustrate the lack of basic "commercial, and security considerations" which existing security settlement solutions have gone though over the last 20 years.  Some of them can be ready addressed in future evolution of bitcoin, others not so sure.. the point is they were not considered, and potentially many more exist today, which can be exploited, leave that task to the "bitcoin" experts.

Some are fundamental security policy issues, others are just basic design defects, and yet others are normal commercial considerations, which any bank or market participant or exchange would traditionally consider, as part of any due diligence on any new protocol.

Transaction Ids and Transaction malleability risk?
Due to a basic design flaw in the bitcoin network.. a lone programmer with nothing else to do,  decided in the first week of October to attack the bitcoin network, by exploiting the transaction malleability defect.
"Whether amaclin is telling the truth is hard to verify. But the fact that he could be telling the truth, the fact that a networkwide attack on the Bitcoin network could be carried out by a bored individual with some coding skills, is probably quite telling in itself."
Gosh, one cannot "trust" every programmer in the world, who would have thought?

"Additionally, amaclin argues that Bitcoin is fundamentally broken. He specifically points out that the incentive structures of Bitcoin’s development process do not align well, as users are not incentivized to reward developers for their work building and maintaining Bitcoin. By attacking the network, amaclin believes he is revealing that only a small number of developers can fix the issue, while most Bitcoin users expect them to do so for free. That is an unsustainable proposition, amaclin says."
Probably the truth?

Front Running?
If a malicious miner sees a big buy order coming into the market that would move the price significantly, they can engage in front running - the buy order could be pushed to the back of the queue or even left out until the next block, while the miner buys up all of the current stock and re-lists it at a higher price to turn a profit. Remember typical security exchanges operate at light speed compared to bit-coin. Alternatively, when they see there is a high market pressure coming in,  they can buy the orders up one by one by using their power to include any number of their own transactions into a block for free, and similarly re-list them for people to buy up.

Smart Contracts?
The miners could also try to influence some time-sensitive contracts - maybe some contract deadline is about to come up and the miner stalls the transaction by one block? That could change the outcome of the contract.

All in all, there is a lot more a malicious miner can skew in their favour within an asset system than they could do in a traditional currency system like bitcoin.

Terms of Service?
There is no terms or service, which "hasher's" follow?
Who are you going to call when that "fat finger" moment occurs, well no-one!, as everyone is anonymous..

Legal Risk?
Any existing legal system will likely never recognise a system of property titles that can be reversed by anonymous or pseudo anonymous "validators". In a number of proposals I have looked at it is impossible to quantify  the probability of a history-reversing attack ( as it is economics based security, not technical).

Regulatory Risk?
An unregulated payments and currency system with no AML, why is it still operational?
The real answer is straight forward, as shown below, this may all change when bitcoin moves from the too-small-to-care into the too-large-to-ignore space?

Sacrificing safety over liveness and fault tolerance
The Fischer Lynch Paterson impossibility result (FLP) states that a deterministic asynchronous consensus system can have at most two of the following three properties: safety (results are valid and identical at all nodes), guaranteed termination or liveness (nodes that don’t fail always produce a result), and fault tolerance (the system can survive the failure of one node at any point). This is a proven result. Any distributed consensus system on the Internet must sacrifice one of these features.

What happens when consensus is not reached: A fork in the ledger.


Security
Any security professional knows that crypto is != to security. Trust (security) is only as good as its weakest link, in the case of bitcoin there is no security policy at all, anyone can do anything including storing "keys" on insecure Operating Systems, the very first real crypto currency Mondex, back in 2001 understood this basic fact, yet some how in the intervening years this fact have been  forgotten. Existing cash, which bitcoin is trying to replace always has had minimal security mechanisms, yet none exist in bitcoin. Like every existing payments system today, at a minimum all keys must be protected within a HSM, pretty basic stuff.

Algorithm Agility, have we not learned anything from the 20 years of electronic payments experience? The cost associated with the DES->3DES->AES changes were enormous as no thought went in originally to the longevity of crypto.. Any block chain ledger must from day one be Algorithm Agile, not only to future proof the system, but also to support different "risk" profiles.
This is the same issue with the payments block chain as well as any secure block chain..

Hash Codes 
I keep seeing people confuse "hash" with encryption in almost every bitcoin discussion; but the more worrying usage is the growing use of hash chains as security enforcing functions. There is a reason why digital signatures are used, and not just hash chains alone. This usage is becoming wide spread in "side chains" and other applications linking to the bitcoin block chain, one such group claims this security "vulnerability" as a "feature". Hash chains, like their precursor hash tables, have there usage; but not in this context, the reasons are two fold a) hash values are not unique, they have collisions, when used in a hash table or chain they have limited scoipe to prevent the effect of any collisions, b) hash chains can easily be changed (recalculated), see asymmetry in POW above. This vulnerability was one of many reasons, why digital signatures are used rather than hash values or even chains alone.
Same old collective amnesia in action again. Hash collisions is the exact vulnerability which was exploited in the successful bitcoin transaction malleability attack above.

Point two, to take away "Hash" values are Not guaranteed to be unique, they only guarantee that a single bit change in input will produce a different resultant hash output.


Commercial Risk
Bitcoin miners can simply stop processing any transactions from any bank they believe does not act in their, or there perceived community interest, this is currently happening in bitcoin today where some miners are ignoring single low value transactions, there is nothing in the bitcoin protocol that required any transaction to actually get onto any block in the block chain.

"About a week ago, lead Bitcoin developer Gavin Andresen quietly introduced a patch that would add a fairly significant change to the transaction propagation rules: any transaction with any of its outputs less than 5430 satoshis (0.00005430 BTC) would be classified as non-standard, and will not be included or further propagated across the network by default miners."

The code could be modified to say all transactions with Address of say ANZ, CBA, or Westpac, will not be processed, there is no one in control of bit coin, anything is possible. Similarly groups using bitcoin to "anchor" other assets, could simply find they are "removed" from the network. Many bitcoin developers already object to "coloured" coins usage of the bitcoin block chain..

Also today, for less than 2BTC in fees an actor can disrupt and clog the bitcoin network for hours..

Control/Ownership Risk
Its a simple fact, all banks, market participants ect, want to own and control the block chain ledgers which underpin their business.  They have shown they are willing to let a third party like SWIFT handle cross boarder, low level connectivity networks but that is about as far as it goes..
The concept of any bank or participant all using a single "uncontrolled" public bitcoin block chain or anything that relies on it, is commercially flawed, and will not fly.

All Banks and exchange participants, "need" to own and control all aspects of the Block Chain Ledger Technologies, without any fear of patent infringements..

System Risk
A settlement system, is much more than just a blockchain. What is required is a complete eco-system which has all the resources to make and keep it secure.
At a minimum it needs

• HSM backed keys
• BYOD mobile device management, loss, theft, compromise
• Secure Identity, with optional full AML/KYC
• Scalable, distributed solution for at last 1 Million transactions per day per settlement node.
• Support for real-time "liquidity" viability
• Support various risk profiles, via selectable algorithms, must be able to address future quantum computing advances without destroying any past transaction.

Where to now?
Ok, so the above is a bleak picture for all those groups, blindly linking applications, other than bitcoin to the bitcoin block chain today..

In short DONT!

KISS to the rescue..
A solution to all of the bitcoin issues above, is very simple to understand and commercially available today, and yes, can support ~ 10,000 tps per distributed node. These Block Chain Ledgers are based on well understood accounting principles such as  "Triple Entry Accounting", which is an evolution, not revolution of double entry accounting, and good old cryptographic "Block Chain".  Block Chains and Ledgers have existed for at least three decades, nothing radical here. These Block Chain Ledgers use tried and tested, for at least the last 20 years algorithm suites (not the one in bitcoin), are algorithm agile, and can transparently adapt to future threats. Expect to see these delivered as total eco-systems i.e "settlement-in-a-box" which can be owned and operated (including patent protection) by various parties, which run in conjunction with existing settlement systems. The existing system will never change, its is not commercially viable..

See just one such solution, the first Payments-> Public Block Chain Ledger.

Lighter side..
As an English speaking person, the  correct description is Block Chain, not blockchain.. the noun is "chain", and the adjective is "block".. see history below...Life is too short sometimes..

History before bitcoin:

1. Double Entry Ledgers, from 1299
2. Hash functions, from 1970's
3. Chain of hash entries, BSD rtable, 1977
4. Merkle tree, Ralph Merkle 1979
5. Cipher Block Chain (CBC), 1981
6. Concept of electronic cash, invented by David Chaum, 1983.
7. Byzantine Generals Consensus algorithms, 1983.
8. Elliptic Curves, discovered by Certicom in 1985.
9. First citation of "block chains" Open-Architecture Computer Systems, 1987.
10. X.509 certificate chain (chain of hash, signed records), 1988
11. FinTech, from 1990.
12. First commercial cryptographic based currency, Mondex 1994
13. Block Chain Ledger, Patented 2000
14. Bitcoin, 2009

Additional reading

The Global Block Chain Ledger, as a Payment System for the Digital World

Transition to T0 Settlement for Cash Equities, the only solution..

Land Registry, on the Public Block Chain ledger

The Unbanked, in the Digital World...

Acknowledgements
http://web.cs.ucla.edu/classes/cs217/Baran64.pdf
https://en.wikipedia.org/wiki/Proof-of-work_system
http://www.slideshare.net/MrCollectrix/the-distributed-ledger-landscape?related=5
http://www.technologyreview.com/news/525676/academics-spy-weaknesses-in-bitcoins-foundations/
http://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf
http://www.cs.cornell.edu/~ie53/publications/btcPoolsSP15.pdf
http://www.technologyreview.com/news/540921/the-looming-problem-that-could-kill-bitcoin/
http://www.technologyreview.com/news/537486/leaderless-bitcoin-struggles-to-make-its-most-crucial-decision/
https://www.youtube.com/watch?v=Lx9zgZCMqXE&feature=player_embedded#t=7
https://erisindustries.com/components/erisdb/
http://arxiv.org/pdf/1311.0243v5.pdf

Without permission, anyone may use, reproduce or distribute any material in this blog for noncommercial and educational use provided that the original source is cited.

Disclaimer The contents of this site should not be understood to be an offer for sale of any payment , currency, security trading or settlement systems, accounting, taxation or investment advice but rather as general educational information that may or may not meet your specific requirements.

Secure Global Digital Identity, for the Digital World

What's worse than paying your taxes? Having an identity thief steal your return payment, the IRS paid out $5.8 Billion in fraudulent returns in 2015.

In Australia we don't have the same SSN issue (the failed Australia Card), which is the root cause of most of the above USA tax fraud, but the expanding use of TFN's, drivers licenses (for ID not driving a vehicle, i.e. functionality creep) is creating the same fraud opportunities here in Australia, ask any of the 770,000 Australian's who suffered from identity theft. The problem is real and no solution exists today.

Principles:
a) personal data shall be exclusively under the individuals control, b) not held in any centralised system, which does not hold a current certificate for a system evaluation to EAL3 at a minimum, this applies to all government as well as commercial systems, c) be held in fewer and more secure places and d) be global and freely available for verification subject to principle a.

Identity Theft is a Global problem, as such this article proposes a Global Solution to protect individuals and organisations, while still allowing the shared "community" objectives like AML ect to remain in place. The current Government, and private industry Identity protection practices, belong to a world which no longer exits, have consistently failed the Individual, and community, and are simply not suitable for the current Digital World. A truly Global secure solution is required which is effective in both the bricks and mortar, and Digital world, and should be publicly accessible and free. The same solution should en power "third world Individuals" to enable a truly global digital world in which everyone can participate.

Ones identity is something we take for granted (after all it is you), and expect the various organisation, including governments we deal with to protect our identity. Yet these same organisation are at the heart of the identity theft problem. All of these organisation tend to blame the "Individual" for any Identity Theft when in fact they are the root cause, and only the Individual is affected by theft of their Identity.

“Digital identity“ is the sum of all digitally available information about an individual. It is becoming increasingly complete and traceable, driven by the exponential growth of available data and the big data capabilities to process it. The issue addressed within this article is the ability to link both the Digital and physical worlds, and how a compromise within the digital world can affect the physical identity, i.e Identity Theft..

The data elements which underpin, most widely used "personal" identifying data, are birth dates, names and addressees, and drivers licence numbers. The aggregation of this data, under pins our "identity", with regard to many Digital Transactions. Many organisations routinely collect this information, some like banks, use birth date continuously.
Information collected for the purpose of AML,should only be used for the specified purposes it was collected for, not for general bank operations, this is clearly defined in the Privacy Act (Section 6.1), yet banks, and other organisations routinely violate this principle. This ongoing violation of the Privacy Act, is one source of Identify fraud, yet continues without any checks or balances.

Today the collection of personal identifying data, has become epidemic, and grows each and every day, routinely night clubs, and hotels (with zero security protection, or regulations in place), photo copy an individuals drivers licence. Banks photo copy drivers licences, birth certificates, even though not required under any legislation. With a drivers licence, a birth date and data readily available from a postbox or even available on line, almost anyone can open a bank account on-line as "you" today. On-line organisation like Google, track and scan all of your on-line and digital activities, collecting any data which lows though your emails or any site you visit, while using systems that have zero security accreditation or any stated compliance with Privacy Principle APP8 (cross boarder data transfers).

Once your Identity is lost, it can be impossible to participate within today's digital and physical world; many find it takes years to address their Identity, after being stolen, their are cases where physical properties have been sold from under their owners.

"Identity crime is now one of Australia’s most common crimes, It’s estimated to cost at least $1.6 billion each year. ID crime is one of the key tools of organised crime groups. Yet Around 20 government agencies in Australia issue more than 50 million documents or credentials used as proof of identity" from DVS transcript.

In many cases, Government departments are the root cause of the problem, by forcing the Individual to provide identifying data when in fact only authentication is required. Additional "function creep" , has become epidemic as data is collected for a specific purpose,and then used for a different purpose, in the case of DVS a unrelated revenue generation purpose. Government departments are the source of almost all Identifying documents, these MUST NOT be outside of the Individuals "control", and must not be used for any purpose other than as collected. This simple requirement is explicitly covered in the Privacy Act Section 6.1 which also applies to Government departments.

A drivers licence is solely for the purpose of authorising an Individual to dive a nominated vehicle, it is NOT an identity card, it is not an Australia Card by default. The whole DVS concept is bizarre. Check out the total absence of even the most basic security for these systems, the best you get is some waffle or links to policy documents, there is not a single Certification available on any Government or Commercial Site. DVS has recently started selling individuals verification to commercial entities, yes using an Individuals data as a means to generate Government revenue, and selling this as enhanced digital security, truly bizarre.

Identity theft is a by product of the issuance and storage of these 50 million documents and credentials within a range of in-secure centralised systems, this is just crazy.

Today there are a range of commercial providers of "Identity" systems, sometimes labelled as Green ID?, mainly to support AML requirements, and many private solutions such as used by banks, and recently Governments via DVS? All of these have fundamental security flaws, they are centralised and the control over the Identifying data is not the exclusive control of the individual but rather the centralised authority. This is is fundamentally flawed concept, as the identifying data MUST be under the control of the Individual or Entity to whom the data belongs, this is so very basic, as only the Individual is affected by Identity Theft, non of these organisation are affected at all, and take no responsibility for any Identity Theft relating to the data they collect and store.

The whole concept of storing multiple copies of ones identifying data all over the planet in in-secure repertories (could not find a single provider who has its systems accredited to ITSEC at even the most basis EAL2 or more appropriate EAL3  level). Not a single operator has published their mandatory security policy which should include as a minimum encryption in transit and storage. See D&B Green ID, VEDA, and from 2015 the Australian Government via their DVS all fail this basic test.

Seriously, does no-one care less about Individuals, and theft of their Identity?

In the security world, centralised systems are known as "single point of compromise", the reason why one sees 100,000 of personal data affected,when one of these systems is compromised (credit card data is typically one such system). Centralised systems are not used for a single high assurance deployment anywhere in the world today, why is Identity data being stored in such insecure systems?

When ones "identity" data is compromised, this data cannot be put "back into the bottle" or fixed, once ones Identify is lost via compromise of identifying documents, one can be totally unable to participate in every day functions, yet the same insecure, centralised solutions are still in use today, as are the ongoing compromise of such systems systems.

Finally after 15 years of R&D and recent advances in cloud security, a solution to address both Identity Theft  and Anti Money Laundering compliance in a single secure and publicly available framework. The end of hidden or secret data storages with no transparency.

As part of the Global Block Chain Ledger network, we have deployed the worlds first totally Global Secure Identification system.

The system is based around a open standard, for a Secure Identification Number(SIN), which is derived from Elliptic Curve cryptography and keys generated and stored within cloud based Hardware Security Modules.

The solution to Identity Theft, is not complicated,
STOP:

• Collecting personal identifying data which is not required to perform the immediate activity, by the requesting entity.
• Storing any personal identifying data in any centralised system.
• Sharing or accessing any personal data without the explicit approval, on a per request basis by the Individual
• Storing aggregated personal identifying data in any System 
• Sharing personal data, outside of the initial receiving entity and system
• Routinely requiring personal identifying data as apart of an authentication process.

In order to prevent Identity theft, in all cases the Customer should be able to provide the "authentication token" to be used by any organisation when requesting authentication. This is very basic security and privacy requirement, and a part of the digital world today.

The fully decentralized, anonymous, secure identity.
Enter the Secure Identity Number(SIN), this is a totally digital identity that may be securely used for any type of transaction within the digital world, including replacement of the traditional username/password.
A SIN(s) is the unique record identifier by which this identity will be known, the key concepts are:

• there is no centralized infrastructure or entity required
• the secure identity is under the total control of the Individual
• can securely support the full range of Identity and authentication requirements

Attributes:

• Ownership can be digitally proven with high assurance, and possible non-repudiation
• Disposable
• Optionally attach sequence of key-value pairs (public proof) and hashes (private proof) to your SIN record. 
• Start out as anonymous identity, and as required, support opt out of anonymity on a per SIN basis, by attaching identifying key-value pairs (real.name = "John Smith").
• All key-value pair updates digitally signed by SIN owner (private key holder) abn=123456
• Third parties may offer digital attestations:
• Identity Verification, Inc. digitally signs a SIN as passing their 100 points check.
• Auction Provider, digitally signs a SIN as having a certain reputation score, on their website.
• Decentralized market users, digitally sign one another's SINs, building a decentralized reputation, social media.

Within the Public Block Chain Ledger, these signed  "attributes" are stored within the industry standard DNS "TXT" records for the entity identified by the SIN. This allows a totally secure, yet publicly accessible resource for any agency to securely query any AML related attributes, anywhere any-time for no cost. 

Customer identification and verification play a critical role in meeting anti-money laundering regulations and for maintaining an accurate customer database.

Address your business’s know-your-customer compliance obligations and reduce the business costs associated with outdated and inconsistent data with our Global Secure Identification Number(SIN) solution.

The World First Global, Secure Identification Number is now publicly available.
Any AML attribute verifications can be performed on-line, anywhere in the world for free.


Also see
http://villagemall-ceo.blogspot.com.au/2015/06/identity-theft-and-digital-world.html
http://villagemall-ceo.blogspot.com.au/2015/06/bitauth-decentralized-authentication.html
http://villagemall-ceo.blogspot.com.au/2015/07/public-block-chain-ledger-navigation.html

The following SIN attributes are supported in Release 1.0:
public enum attributeType
        {
            dob, // Date of birth
            adr, // Address
            bus, // Business number (abn)
            tax, // Tax number (tfn)
            drv, // Drivers licence
            pas, // Passport
            age, // Age card
            nam, // Individual name
            cpy, // Company, Trust ect name
            act, // Account, value is free form ASCII. Meaning within context of signing entity.
            bic, // Swift Code/Bank Identification Code
            lmt, // Payment Limit, value in local currency of signing entity
            rev, // Social Review of this entity, value is review scale of 1 to 10 where 10 is highest
            rat, // Social Reputation, based upon eBay rating, converted to a scale of 1 to 12
            rvk  // SIN is revoked, value is date of revocation, this makes any SIN disposable.
        }

Disclaimer The contents of this site should not be understood to be accounting, taxation or investment advice but rather as general product related educational information that may or may not meet your specific requirements.

BlockAuth, Decentralized Authentication for the digital world.

BlockAuth, is a new light weight, password-less authentication protocol, based on the same cryptography used in the bitcoin protocol. Eliminating centralised, server-side storage of shared secrets, and drastically reducing the impact of a compromised server. While designed to support a Block Chain Ledger within a range of financial transactions, can be applied to any existing and future Internet based system requiring secure authentication, especially all mobile platforms.

The majority of computer and internet authentication systems today, are based upon username and password pairs. The username is a unique identifier (usually an email address), the password the shared secret between the user and the system to which access is being granted. Some of the more security conscious systems (HSBC, BofQ, Amazon, Google ect) offer an additional one-time-password, usually based upon something one "has" to form an authentication triple.

The problem with these, and other systems, is the need to share and protect a secret, and the aggregation of these secrets within a centralised system:

• all smart cards need a shared secret key (typically DES key) loaded, CC, SIMs ect
• MFA and all one-time-passwords need a shared "seed" secret
• passwords are a shared secret

BlockAuth is a way to achieve secure, authentication using the same elliptic-curve cryptography as Bitcoin. Instead of using a shared secret, the client signs each request using a private key and the server checks to make sure the signature is valid and matches the public key. A nonce is used to prevent replay attacks and provide sequence enforcement, every BlockAuth signature is unique.
BlockAuth additionally supports mutual authentication between the client and the remote service.

BlockAuth is designed as a light weight, secure authentication service, which leverage's the Bitcoin free software base, be it with commercial EC curves, to allow mobile platform applications(APPS) to mutually authenticate with a wide range of internet accessible services or peers.

BlockAuth make use of a Secure Identification Number, or SIN, a fully decentralized, anonymous, secure identity, based on a the same bitcoin ECDSA key pair, SIN is an integral part of BlockAuth. The SIN supports both persistent, or ephemeral identifier, as well as the ability to opt out of anonymity as required. The SIN can be given to any number of remote services and there are for all practical purposes an unlimited number of SIN's for each client. The SIN is analogous to a bit coin address, as it takes the following form: base16check( 0x01 + ripemd160( sha256( pubkey) )

Typical authentication flow..
Client Application-> Server

1. SIN Registration: register your SIN with the remote service using a mechanism of your choosing generally, this takes place with client registration
2. Submitting Requests: requests are made over HTTP, with an x-signature:
1. generate a unique, unix timestamp
2. include nonce in your request
3. concatenate and sign URI + BODY with your private key, and provide it in x-signature
3. Remote Service: 
1. extract the public key from the ECDSA message signature
2. verify the signature
3. compare the public key against the registered SIN
4. Compose Response using similar form to above, but with remote Service details.
5. Response Body to include an optional expiry, pairing codes
4. Receiving Response: 
1. extract the public key from the response ECDSA message signature
2. verify signature
3. compare public key against with Remote Service SIN, received at registration.
4. Store any one-time use paring codes

BlockAuth Detached, Time Stamped, Signature

Based upon the international standard DER signature, extended with the addition of  "curve" and "timestamp" field elements. These extensions are downgrade comparable with the standard DER signature. This signature is also used within our Secure Block Chain Ledger, so can be utilised across multiple solution sets.

The timestamp field has several objectives, a) as the nonce, b) as a distributed, higher sequence number, c) as an expiry stamp for any key compromise processing, d) secure time stamping service for the signature. The time-stamp is appended to the message hash and hence bound to the signature.
The curve field supports our algorithm agility.

As a detached signature, this design can support the application of  multiple signatures if required.

The BlockAuth signature carries the public key. This removes the requirement to find the public key and allows secure linkage to the SIN attributes as part of any transaction processing.

DER ECDSA Extended Signature
C# Example Code
int recId
BigInteger r
BigInteger s
BigInteger unixtime
string  x-signature

            using (MemoryStream der = new MemoryStream())
            {       
                DerSequenceGenerator seq = new DerSequenceGenerator(der );
                seq.AddObject(new DerInteger(r.Value));
                seq.AddObject(new DerInteger(s.Value));
                // extensions
                seq.AddObject(new DerInteger(version.Value);
                seq.AddObject(new DerInteger(unixtime.Value);
                seq.AddObject(new DerOctetString(pubkey));
       
                seq.Close();
                x-signature  =  BytesToHex(encoder .ToArray());
         }

Example
pubkey:
"02326209e52f6f17e987ec27c56a1321acf3d68088b8fb634f232f12ccbc9a4575"
SIN:
"Tf3yr5tYvccKNVrE26BrPs6LWZRh8woHwjR"
x-signature: 
"304d02207693ad890971718ac5061a9abfdc2a699835e01cb296da8102a6b7d3c7b77e45022009f2b47605c01453d683ef4995660dcaff6e9927864d1bb016af67dc2787f40902011c0204557c38b2"

Note: Hex is used for clarity above, normally base64 encoding would be used for all byte[] structures.

BlockAuth Sessions

While one can  use the above dialogue to support a "stateless authentication" scheme, many existing systems make use of a "session" in which the above process is the initial handshake or login process. In order to support these types of systems, BlockAuth can optionally make use of ECDH key derivation process,  to derive an out-of-band shared session secret between the client and remote service or peer. This shared secret can be combined with the return "expires" time stamp to generate a secure "session token" for all subsequent requests. A typical usage is to combine this ephemerial secret with the HOTP protocol to produce a secure One Time Password solution.
Schemes which could make use of this shared secret are:

1. JSON Web Token scheme

2. AWS scheme

Signature = URL-Encode( Base64( HMAC-SHA1( DHSecret, UTF-8-Encoding-Of( StringToSign ) ) ) );

StringToSign = HTTP-VERB + "\n" +
    Content-MD5 + "\n" +
    Content-Type + "\n" +
    Expires + "\n" +
    CanonicalizedBitAuthHeaders +
    CanonicalizedResource; 

Pairing Token
BlockAuth supports the use of a paring token, this is a one-time-use token which can be used to access specific resources, via a specific role and or device ( mobile phone, tablet ect). This may be bond to a specific device Identifier, such as an IMEI code ect..

Replacing Usernames and Passwords

Simply replace username with a SIN, and password with x-signature, this provides a one time password approach, with no pre-shared secret.

Backward comparability: key the BlockAuth processing from the username SIN keyword prefix  "01" (base16 encoded)  which should be sufficiently unique, given most usernames are human related today.

BlockAuth is available for all Cognition API users, and SIN's will be provided along with the free ECDSA, and ECDH  keys and secure key pool chain available for all subscribers from the 1st July 2015.

C# Code
1. SIN Generation
                // Get sha256 hash and then the RIPEMD-160 hash of the public key.
                byte[] pubKeyHash = PubKeyHash;

                // Convert binary pubKeyHash, SINtype and version to Hex
                String SINversion = "10";
                String SINtype = "1"; //static
                String pubKeyHashHex = Utils.BytesToHexString(pubKeyHash);

                // Concatenate all three elements
                String preSIN = SINversion + _SINtype + pubKeyHashHex;

                // Convert the hex string back to binary and double sha256 hash it leaving in binary
                byte[] preSINbyte = Utils.HexStringToBytes(preSIN);
                byte[] hash2Bytes = Utils.DoubleDigest(preSINbyte);

                // Convert back to hex and take first four bytes
                String hashString = Utils.BytesToHexString(hash2Bytes);
                String first4Bytes = hashString.Substring(0, 8);

                // Append first four bytes to fully appended SIN string
                String unencoded = preSIN + first4Bytes;
                byte[] unencodedBytes = new BigInteger(unencoded, 16).ToByteArray();

                String encoded = Base16WithCheckSum.Encode(unencodedBytes);

Also see
1. Free hardware generated and protected Bitcoin Private key and key-chain.
2. Identity Theft and the Digital World..


Disclaimer The contents of this site should not be understood to be accounting, taxation or investment advice but rather as general product related educational information that may or may not meet your specific requirements.

Identity Theft and the Digital World..

Ones identity is something we take for granted (after all it is you), and expect the various organisation, including governments we deal with to protect our identity. Yet these same organisation are at the heart of the identity theft problem.

“Digital identity“ is the sum of all digitally available information about an individual. It is becoming increasingly complete and traceable, driven by the exponential growth of available data and the big data capabilities to process it. The issue addressed within this article is the ability to link both the Digital and physical worlds, and how a compromise within the digital world can affect the physical identity, i.e Identity Left..

The data elements which underpin, most widely used "personal" identifying data, are birth dates, names and addressees, and drivers licence numbers. The aggregation of this data, under pins our "identity", with regard to many Digital Transactions. Many organisations routinely collect this information, some like banks, use birth date continuously, even when precluded by the Privacy Act.
Today the collection of personal identifying data, has become epidemic, and grows each and every day, routinely night clubs, and hotels (with zero security protection, or regulations in place), photo copy an individuals drivers licence.  Banks photo copy drivers licences, birth certificates, even though not required under any legislation. With a drivers licence, a birth date and data readily available from a postbox or even available online, almost anyone can open a bank account online as "you" today.

Once your Identity is lost, it can become impossible to participate within today's digital and physical world, many have taken years to address their Identity after being stolen, properties have been sold from under owners.

In most of these cases, and almost all commercial transactions, within the digital world we all live in "Identity" is actually not required, what is required is positive "authentication".

A typical example is buying and selling or commerce, for most of history, this has been done via stored value tokens, or "money". Coins or notes issued by national banks have zero linkage to any Individual, they simply circulate within the community and are exchanged for goods or services.

The majority of commercial contracts are finalised with a "Signature" which also has zero identity requirements, the thrust of a signature is to support non-repudiation.


Enter The Digital World..
In this world everything changed, all of the previous 1000+ of years of  commerce was thrown away..
All of a sudden (in relative time), there was introduced the need to "Identify", primary due to an Orwellian need by governments and organisations to track various "individuals and their activities in the digital world, the infamous "Australia Card" was perhaps the best example, yet while rejected by the population, has been introduced via TFN's and drivers licences, and data aggregation, without the individuals informed consent.

Putting aside these "political" issues, and looking at the real risks associated with the wide ranging collection, centralized storage and sharing  of "identity" information, without even the most basic security.

There is simply no reasons for any individual to provide anyone with their birth date, ever, unless one wants to celebrate such an event.
If a bank wants to verify a client, then they need to preferably allow the client to provide an authentication "token" or they should provide one to the customer, in no case should a personally and irrevocable birth date be used, its simple... one cannot change ones birth date if the usage is compromised.

The key to securing any Identity, is the removal of the need for any "centralized solution, and to ensure the control of any "identity" remains solely with the Individual.

The solution to Identity Theft, is not complicated,
STOP:

• Collecting personal identifying data which is not required to perform the immediate activity, by the requesting entity.
• Storing any personal identifying data in any centralized system.
• Sharing or accessing any personal data without the explicit approval, on a per request basis by the Individual
• Storing aggregated personal identifying data in any System 
• Sharing personal data, outside of the initial receiving entity and system
• Routinely requiring personal identifying data as apart of an authentication process.

In order to prevent Identity theft, in all cases the Customer should be able to provide the "authentication token" to be used by any organisation when requesting authentication. This is very basic security and privacy requirement, and a part of the digital world today.

Authentication in the Digital World.
The most common form of authentication in usage today is the "user name" "password" duple.
The username is not required to identify the user, but rather to be used as a "synonym" and the shared secret is the "password".

The fundamental security flaw with this scheme, is the need to have a "shared" secret the password. if the "secret" is not keep secret or managed correctly then the authentication scheme will fail, read can be compromised. A credit card is a simple variant, i,e a CC number is the synonym and the Pin is the shared secret. there is nothing secret about the CC number.

A digital Solution for the Digital World..
As Identity theft is a by product of the increasing use of the digital world, then the same digital world needs to provide a solution.

The fully decentralized, anonymous, secure identity.
Enter the Secure Identity Number(SIN), this is a totally digital identity that may be securely used for any type of transaction within the digital world, including replacement of the traditional username/password.
A SIN(s) is the unique record identifier by which this identity will be known, the key concepts are:

• there is no centralized infrastructure or entity required
• the secure identity is under the total control of the Individual
• can securely support the full range of Identity and authentication requirements

Attributes:

• Ownership can be digitally proven with high assurance, and possible non-repudiation
• Disposable
• Optionally attach sequence of key-value pairs (public proof) and hashes (private proof) to your SIN record. 
• Start out as anonymous identity, and as required, support opt out of anonymity on a per SIN basis, by attaching identifying key-value pairs (real.name = "John Smith").
• All key-value pair updates digitally signed by SIN owner (private key holder)
• Third parties may offer digital attestations:
• Identity Verification, Inc. digitally signs a SIN as passing their 100 points check.
• Auction Provider, digitally signs a SIN as having a certain reputation score, on their website.
• Decentralized market users, digitally sign one another's SINs, building a decentralized reputation, social media.

Within the Cognition Public Block Chain Ledger, these signed  "attributes" are stored within industry standard DNS "TXT" records for the entity identified by the SIN. This is just one of the many possible options for securely linking and distributing public attributes to the World.

The technical bits

The solution makes use of existing global software and infrastructure, a simple add-on..

SIN, is a new form of identity based on a cryptographic key pair. SINs were originally proposed by Bitcoin Core Developer Jeff Garzik,

The SIN is analogous to a Bitcoin address, as it takes the following form:

base16WithCheckSum( 0x01 + 0x02 + ripemd160( sha256(k1) )

Where k1 is your public key from an ECDSA keypair. 0x0F is the special byte for SINs, and 0x02 is the type of SIN; in this case, an ephemeral or standalone identity.

This SIN can be shared openly with the world, as the corresponding private key is kept on the client-side and never transmitted over the wire, and never shared with any entity.

How does Secure Identity Number(SIN)  based  authentication work?
The general flow to authenticate a request is as follows.

• Key generation: Individual generates a key pair k using ECDSA (use a free ECDSA key chain service).
• SIN construction: with public key k1, concatenate the SIN version byte and hashed public key, then encode this in the base16WithCheckSum format.
• SIN sharing: register your SIN with the remote service using a mechanism of your choosing generally, this takes place with client registration.
• Submitting Requests: requests are made over light weight HTTP/JSON, with the x-signature and x-identity header:
• generate a unique, higher-than-previous nonce, we recommend using a "unix time" integer, and include in as the  nonce HTTP parameter of your request
• include your compressed bitcoin public key (hex encoded string)  in the  x-identity header 
• if JSON body is included, set content type to  "application/json"
• concatenate and sign base URL + URI + JSON with your private key, and provide the resulting bitcoin message signature as a hex encoded string in x-signature
• Receiving System: will validate request using x-signature and x-identity header:
• check x-identity against stored SIN
• use x-identity header and posted data to validate x-signature
• optionally check any attributes linked to the registered SIN.

The server will now verify the signature against the public key you've provided and the SIN you've shared previously (does not need to be a secret), confirm that the signed nonce is greater than this SIN’s previous nonces (preventing replay attacks), and subsequently authenticate the request.

Replacing Usernames and Passwords
The authentication scheme is directly compatible with the familiar username (or email) and password mechanic. The primary difference is that the password is never sent over the wire, in any format.
Using this mechanism, you can still provide the user with the experience of entering a username and a password, but locally use that password to decrypt the private key and subsequently use it to sign the request.

Advantages over existing authentication mechanisms
Gone are the days when a single hacker, can compromise an entire customer base's credentials, the removal of all shared secrets, is the key to improving on-line security. In the above, passwords are only used locally, to encrypt the private key.

• Support for per transaction (ephemeral)  as well as persistent SIN's to manage scope of any compromise. 
• Only a compromise of the client machine can endanger the system, and hardware backed ECDSA keys can readly address this possibility.
• Because the private key is never revealed to the server, it does not need to be exchanged between the server and client over a side channel, there is No Shared Secret to compromise.
• Piggy backs on the global, and freely available Bitcoin protocol infrastructure, no central PKI is required.
• Decoupled from Bitcoin addresses, allowing for a more explicit separation from financial transactions and allowing for greater privacy, also allows support for algorithm agile solutions
• Support for persistent, and ephemeral SIN's to manage compromise
• Identity becomes portable the same identity can be used on multiple services, letting you take your identity with you.

It's time, for Individuals to take control over their digital Identity and how or when their data is used and stored.

What if I need to prove my identity?
Within a community, there are situation where is is required provide an assurance of "identity", a simple fact of living in a community.
The SIN framework has been designed to allow an opt in to a "set of signed attributes" on a per SIN basis and still under the total control of the individual.

Why should Corporations and Governments world wide, care about personal data?
BCG estimates that two-thirds of the potential digital identity value – or about €440 billion in 2020
alone – is at risk if stakeholders fail to protect personal data.
Nor is it digital identity value alone, the additional revenues or efficiency gains derived from personal data applications are at risk: Mishaps in handling consumers‘ data can go much further, causing damage to an organisation‘s brand, its client relationships and its reputation. Privacy is increasingly becoming an area of competitive differentiation.

Usage today

All Subscribers to VillageMall have a hardware generated and secured ECDSA key, and type 1 SIN incorporated, for free, with their subscription.
The worlds first Global Digital Identity Service with SIN attributes is now operational, and publicly available (see DNS domain blockchainledger.net)

The first usage is to secure our Cognition API, including BYOD management system, used to manage lost, stolen or compromised Mobile Devices and access to Cognition Suite of Services.  

See Free hardware backed ECDSA Keys and SIN

References:
1. Data from fraud prevention service Cifas shows ​​34,151 confirmed instances of identity fraud were recorded in the first quarter of ​2015​.
2. Prevent identity theft 
3. Number of identity theft victims 'rises by a third'

Disclaimer The contents of this site should not be understood to be accounting, taxation or investment advice but rather as general product related educational information that may or may not meet your specific requirements.

Triple Entry Accounting, and Secure Block Chain Ledgers..

The magic in this space is what we sometimes hear called triple entry, which is highlighted by the bitcoin block chain’s success in mounting an independent currency over a shared ledger.

We all know how insubstantial internal ledger entries are, and how we can really only rely on them to the extent that we trust our internal processes (e.g. who can forget the Enron events of 2007 leading to a popular view that accounting and audit have failed us).

On the other hand, we also see how solid payment systems are. Whether bank- or Government- or private-run, payments generally work. When these multi-party activities do not work, all hell breaks loose, and people run, sometimes quite literally, to other systems.

When accounting ledgers break, we sigh and move on. Triple entry, via Block Chain Ledgers takes us from the unreliable fantasy of the accounting entry to the hard concrete reality of the payment: the secure distributed Block Chain Ledger is as solid as a bitcoin payment.

Quite simply, the basics of accounting have not changed for hundreds of years.
Today, the many well known issues are trying to be addressed by formulating new rules, employing more auditors and investing in more IT infrastructure. This is the wrong approach.

I believe most of the above are solvable by doing four things;

1. Make accounting of a business activity an integral part of that activity. Instead of treating it as a separate process. What if the invoice was the journal?
2. Sharing data between entities. Any business transaction involves an agreement of value by one or more parties. Privacy is not a problem as all parties should be recording the same data.
3. Using cloud accounting ledgers. Enterprises maintain simple private ledgers. Cloud APIs allow for easy integration and the development of APPS.
4. Securing each ledger, with private block chains, brings existing accounting systems into today's digital world, without throwing away everything ( like bitcoin has done).

Bitcoin achieves the first two things for cash payments. By creating and signing a Bitcoin transaction, one generates a proof (which is consensus verified) that the transaction happened and they had the rights & obligations to the unspent transaction outputs referenced in the transaction.

This doesn't mean that bitcoin should replace double entry,rather it augments the traditional accounting system ledger by providing a way for parties to share certain transactions as if they were as solid as payments.

E.g., when Alice Ltd wants to pay Bob Ltd, Alice will no longer rely on its accounting systems alone to describe this situation, and neither will Bob. Both of these parties will share a “receipt” that is cryptographically signed by some party that has mediated it (could be an existing bank such as ANZ, the Reserve Bank of Australia, or it could be VillageMall).

Triple entry accounting is very simple, as shown above, there are three parties, each holding a copy of the same receipt, hence the label "triple entry". In the Bitcoin world, that middle inter-mediator is the bitcoin block chain and the two other parties are the Wallets.

The receipt or public book above, itself is strong because it is cryptographically authorised by the payer, and cryptographically signed off by the mediator (as a minimum). It represents such solid evidence that it is practically irrefutable in terms of the facts on record, and it is trivially automated in audit terms.

Holding this entry is far more flexible than Alice and Bob relying  solely on their double entry systems because firstly you can build the double entry systems out of the collection of receipts any time you need them, and secondly, it is so strong that it can be used as evidence to create derivative claims. E.g. it’s a set-up for securitisation or loaning contracts or other more advanced uses. And, it’s a lot easier to audit because it is such solid evidence.

Back to bitcoin and its block chain. This is the first social experiment in a large scale triple entry issuance. In part, seeing what happens on the block chain generates excitement because we perceive an ability for any company to turn its stalled internal assets into contracts that are then dynamically mediated through cryptographic receipts.

Once one can issue all the accounted assets into a triple entry arrangement that others will instantly respect, finance will democratise.

Savings for every Accounting Ledger
According to Santander (2015), "distributed ledger technology could reduce the banks' infrastructure costs attributable to cross-boarder payments, securities trading and regulatory compliance by between $15-20 billion per annum by 2022".

So where are we at today?
With the release in 2004 of commercial Block Chain Ledgers the double entry accounting of each party Alice and Bob can now be secured, and audited via their individual "Private" Block Chain Ledgers. With the introduction of a intermediary or Public Block Chain Ledger (public ledger above), and communications based upon existing bitcoin block chain protocols, today we have a full implementation of a commercial "triple entry accounting".

Where each end accounting system and the intermediary public block chain provide a "secure"  distributed triple entry ledger.

This concept can be expanded, Bob above can maintain a local ledger containing all its adjustments, however it can also maintain a distributed ledger which contain details of all transaction or contracts. As the distributed ledger is agreed upon by all participants and there are digital signatures to provide a degree of non-reputability, Auditors can rely on this ledger. The auditors job starts getting easier, finally the digital world helps to secure old world double entry systems.

Worked Purchase Contract Example:
1. Alice -> Purchase Widget from ->Bob.
2. Bob  ->Ships Widget and Invoice -> Alice
3. Bob -> Posts journal  DR Account Receivable, CR Income to Private BCL
4. Posts Transaction, with unique TxnId to Public Block Chain Ledger(PBCL)
5. Alice-> Posts Transaction DR Expenses, CR Accounts Payable to Private BCL
6. Post transaction with same TxnId to Public Block Chain Ledger(PBCL)
7. PBCL-> combines messages 4, and 6 along with their signatures (Contract)
8. PBCL-> countersigns and timestamps the combined message 7, along with transactions (i.e DRs and CRs)  and posts to the PBCL.

Worked Payment Contract Example:
1. Alice -> Pays ->Bob.
2. Alice-> Posts Transaction CR Bank, DR Accounts Payable to Private BCL
3. Posts Transaction, with unique TxnId to Public Block Chain Ledger(PBCL)

4. Bob->Receives Payment->From Alice

5. Posts journal  CR Account Receivable, DR Bank to Private BCL
6. Posts Transaction, with unique TxnId to Public Block Chain Ledger(PBCL)
7. PBCL-> combines messages 3, and 6 along with their signatures (Contract)
8. PBCL-> countersigns and timestamps the combined message 7, along with transactions (i.e DRs and CRs)  and posts to the PBCL.

I believe that while the above could represent a practical Public Block Chain Ledger,  the commercial reality is likely to drive a range of specialist PBCL, i.e. each focused on a specific use case. Collectively these will form the globally decentralised Public Block Chain Ledger.  Each segment of the PBCL is navigated using Internet DNS entries, within the domain blockchainledger.net. An example of a reference specialist "payments" PBCL is provided at the end of this article.

In the case where a bank is offering the PBCL the changes to the above example are trivial. The point is all types of interactions P2P or traditional intermediary are supported. In the case of a bank intermediary, the Public Block Chain Ledger for each entity would simply be their "Bank Statement". The unique aspect of an architecture with both private and public Block Chain Ledgers, is that the distributed PBCL supports all "between" entity transactions, and hence the concept of "gateways" as used in almost all crypto-currencies is not required. With the PBCL and P2P transactions there is no settlement or clearing delays, as all entries are atomic and instantaneous. In the case of no intermediary there are some addition joint signatures required to secure the transaction, over the intermediary signature used, but all standard crystallographic techniques.

The fully distributed Global Public Block Chain Ledger is the record of truth, and available to all, the atomic nature of all Block Chain Ledger transaction, allow instantaneous transfers to occur.

In fact when the PBCL is applied to P2P payments, we do not see why all payments should not be free, as our analysis shows the incremental cost is close to zero, and each Private Block Chain Ledger can easily support its part of the decentraliced PBCL. The same could be applied to all commercial transactions which are capable of being processed though an accounting system,virtually everything.

An enhancement within the Block Chain Ledger over bitcoin, allows each and every block to have a unique private ECDSA key and the digital time-stamped signature, is applied atomically to each transaction block, This enhancement allows instantaneous sealing of each block and all transactions in time, plus traditional bitcoin identification of each block (address) and hence the ability to instantly post to the PBCL, this also supports detection of duplicate transactions, as the private Block Chain Ledgers cannot be changed or altered in any way by either Alice or Bob, the PBCL can request the parts of the block chain necessary to validate each Private Block Chain Ledger before signing the triple entry.

The public block chain ledger provides a real-time, atomic transaction, and reporting system.
The atomic transaction is completed once the PBCL entry in 8 above is posted to the PBCL, each party Alice and Bob and anyone else can verify the "Contract" or transaction, with a deterministic level of non repudiation.

An auditor can request all transaction data, and if required can counter sign, a Block within the PBCL and hence bind parts of both Alice and Bob's private Block Chain Ledger and also the PBCL in time (see BlockAuth detached time-stamp signature specification).

The point is that if one is inherently happy about Transactions then the accounting and audit process becomes much more simple; no need for reconciliation's or for an auditor to mess about with 3rd party confirmations (which are almost never returned!). An auditor can also gain 100% assurance into existence and completeness of transactions with counter-parties – this is the holy grail of audit.

As mentioned in the above comment, this is super useful, not only for audit. Due diligence, tax reporting, generating data for financial reporting also benefit, in fact almost everything benefits form this approach.

Bitcoin already contains a set of protocols which will allow interaction between each Private Block Chains and the Public Block Chain, with minor tweaks, this existing code and network, allows a kick start to a more commercial set of Block Chain Applications, that in most part have nothing do with digital money. Additionally as the Block Chain Ledger is based on traditional double entry accounting systems a mixture of P2P and more traditional Public Block Chains can be utilised. As above the Reserve Bank could run an inter banking Block Chain Ledger, that has all of the existing frameworks, but in this case actually secure and suitable for the modern "digital" world we all work in.


Welcome to the Internet of Value.
The intermediary Block Chain Ledger is in fact "signing off" or witnessing, both sides of the block chain ledgers transaction, this is in fact the "Contract" process, the ledger Transactions could be stock trading, property sales, or in fact anything that can be processed though a standard double entry accounting system.

The Internet of Value’s ubiquitous, seamless, comprehensive and secure method of transferring value allows for the distribution of value in all sorts of novel ways.

Some obvious use cases:

• syndicated loans
• trade finance
• supply chain provenance
• asset provenance
• clearing/settling
• cross boarder payments
• inter-bank payments
• identity/data authentication
• private stock/equity issuance
• contracts 
• global P2P payments

Implementation example.
Theory, is fine, but one also needs concrete commercial examples, one such implementation is The Cognition Cloud Accounting Engine, which due to the design, as a modern Cloud based double entry Accounting Engine; which is required to process high volumes of transactions, the internal design is consistent with the design requirements of a Private Block Chain Ledger, in fact each cognition ledger has a fully integrated Block Chain today, using existing bitcoin technologies.
The BlockAuth Detached, Time Stamped, Signature , has already been implemented in commercial Private Block Chain Ledgers, such superannuation funds in 2015.

The building blocks are here today, allowing companies to run their own secure private block chain ledgers, and also allow future integration with a public Block Chain Ledgers.

Reference Implementation
In the reference implementation, using a commercial hash keyed database, ~10,000 blocks per second could be processed. This is for each of the distributed Public Block Chain Ledger(PBCL) node within the PBCL's. Hence the total processing of the PBCL is practically unlimited. The reference implementation supported ~ 5,000 read operations, this asymmetry is typical of commercial databases.  This performance is relatively independent of the number of transactions in the distributed PBCL

Performance Comparison:

·         Bitcoin 7 tps

·         PayPal 115 tps

·         PBCL 10,000 tps for each BPCL node, unlimited across the global PBCL

·         Visa network 56,000 tps

Storage Comparison

·         Bitcoin, at very high transaction rates each block can be over half a gigabyte in size

·         PBCL typically less than 10 KB per transaction

Update 2016.
We have released the first Block Chain Ledger Payments Rail, which implements "tripple entry" accounting as described in this article. In addition the worlds first Bank International Settlements defined DvP Model 1, atomic cross ledger settlement..
See The Holy Grail of Settlements

Details:
The Global Block Chain Payment Rail
The Global Block Chain Securities Settlement Rail

Also see
1. Free hardware generated and protected Bitcoin Private key and key-chain.
2. Identity Theft and the Digital World..
3. Navigating the Public Block Chain Ledger

Disclaimer The contents of this site should not be understood to be accounting, taxation or investment advice but rather as general product related educational information that may or may not meet your specific requirements.