Free, Real-time Gross Settlement system (RTGS) for everyone, with a mobile phone.

Today, "money" is a in all cases a bag of bits within a computer system, gone are the days of bank vaults, guards or burglar alarm systems. Money is today sent for close to zero incremental cost between computers. The real costs involved in monetary payments, is securing the 100+ year old double entry accounting systems, and the mass of clerks and auditors who keep  "payment systems" and decade old payment networks like SWIFT running, and manage the risks associated with any losses. To be fair there is a "significant" regulatory cost imposed on banks, and payment systems as well, but these do not match the excessive payment fees which exist today, this is what creates the opportunity. If existing financial institutions offered a free payment service, or close to costs, once they isolated or upgraded their old world insecure accounting systems, than a new global service would get wind in its sails. The system proposed herein is the next generation of Real-time Gross Settlement Systems (RTGS) where all transactions are atomic, instantaneous and irreversible, and have the ability to execute in a distributed orchestrated data and processing environment, including P2P, even if the P2P is not the most likely first commercially deployable option.

Back to reality
An observation; there is "significant" amounts of money going into bitcoin related "block chain" activities, which will never become "verbs" such as to "Google" to "Xerox". There is no truly disruptive technologies evident in this space, which is probably not surprising given the focus on banks and their involvement combined with the massive amounts of profits made from processing payments today. A free payments system is simply not on anyone's agenda, it is typical to see recent graduates as heads of Banking block chain groups, or it is a part time activity for the non executive banking staff..

Like most entrepreneurs, one looks to the "big vision" which can "change the world", and make life better for all. Making money comes as a by product of achieving the "vision" or getting as close as possible, a fundamental different view of the world from the typical banking executive.

The Bill Gates foundation has spend billions trying to solve third world health problems, such a malaria, a free payments system which creates wealth for individuals, can more effectively address third world health issues, than any cure. Poverty unpins many third world heath problems.

There is a saying "Teach a man to fish and he can feed his family forever" in this case enabling third world populations to securely participate in the global economy, we envisage will bring lasting change for the better for everyone. The "Vision"..

Hence if payments, are the focus, rather than a total "Block Chain Ledger for Everything" solution, a vision which is consistent and a subset of the Secure Block Chain Ledger Vision, is a world with a fully decentralised and totally free payments system which is available to anyone who has only a mobile phone.






If one looks at the bitcoin network, it by design drives up the cost of a each transaction, some say its sits at ~$10 per transaction today, totally the wrong approach, its this basic.

Considering the references listed below, if one combines "triple entry accounting", the Private and Public Block Chain Ledgers and Secure Identification Numbers(SIN), and lastly BlockAuth then the implementation of a secure payments system becomes very simple, especially as almost all of the technologies required exist as freely available software today. To support a wide range of eCommerce, the same protocol supports orders and invoicing as well as payments, the two should not be separated.

As all public Block Chain Ledger entries are atomic and instantaneous, and in reality have close to zero incremental cost, then all payments should also be free, this underpins the vision.
We expect the wide availability of free payments, to have the potential to increase the GDP of many third world individual and countries, and lead to an improvement in the wealth of  all.

Today Cloud Accounting for sole traders, and Superannuation Funds is free, no-one needs to pay for accounting software, why not free payments as well.

This result will be truly disruptive to the existing old world, when combined with a fully decentralised Public Block Chain Ledger, and secure payment protocols, making use of the almost universally available global mobile phone platform and free software.

Key Features

• All payments less than a threshold, say $10,000 are Free
• Real-time, atomic, cryptographically secured, fully decentralised Public Block Chain Ledger, participating in a "Triple Entry" accounting ledger protocols.
• Explicit for FX transactions as required, no explicit gateways or exchanges required.
• All transactions appear instantly on the distributed distributed Public Block Chain Ledger
• Requires only a mobile device, with internet access,lightweight data usage
• Suitable for both first and third world participants, bring into the commercial world the existing disenfranchised populations.
• Supports payments to and between individuals who lack first world bank accounts or  identification
• Based upon well known double entry accounting systems, with addition of secure Block Chain Ledger technologies. Private Block Chain Ledgers do not need a single or standard technology solution set, only that they can publish and participate in supporting the global distributed Public Block Chain Ledger protocols
• Reuse of as much bitcoin technologies and available free software as possible
• No bank account required
• Saleable from micro payments though to any value, recognising there may be additional measures required to address additional risks or compliance requirements.
• Supports anonymous and non anonymous payments via SIN and SIN attributes.
• Non anonymous SIN required for all transaction amounts above $10,000.
• Support for commercial Orders and Billing within common payments protocols
• Any taxation is held within the Private Block Chain Ledgers, all payments are considered tax free as is the case today.
• Makes use of IMEI within Mobile device SIM cards.
• Practical unlimited value, is capable of being held within the distributed Public Block Chain Ledger, there is no hard protocol limits as there are no limits within the underlying double entry accounting systems. No wealth or money is created within the Public Block Chain Ledger or payments system.

What about Banks
What do financial institutions want?  Cryptographically verifiable settlement and clearing systems that are globally distributed for resiliency and compliant with various reporting requirements.

What role would banks play in a distributed free value transfer world?
Banks can continue with their existing functions, especially in the early stages, but are not a fundamental element of the solution space, especially for sub $10,000 value transactions with SMEs involved in  B2B, C2B and C2C type payments. In fact banks can use these same underlying technologies to bring their own ledgers into the modern digital world we all live in.

They also play a role in the Secure Identification Number (SIN), when there is a requirement for non-anonymous attributes being applied to the SIN, to support a range of commercial payments and regulatory frameworks, but like above this is not a mandatory element of the solution. And other providers will appear over time, like market place "ratings ect) all variations of SIN attributes are supported. One of the objectives is to support payments from people who have no bank accounts and no first world identification today, and are locked out participating in global eCommerce today.
The one palce that banks will still maintain an dominant position is the supply of "cash" most likely via ATM's for the various local communities, we don't envision the total replacement of "cash" and do not see anyone removing the dominance and convenience of ATMs, we would hope that they can be integrated into the free payments network, even if "cash" dispensing will probably never be free.

Banks also have significant risk management expertise, and in many cases this is a requirement of a successful transaction, especially as the transaction value increases.

But banks are optional parties within any payment transaction, it is the participants choice, in any decentralised solution, Opt-in is always the prim objective.

Why Mobile Phones
In many third world countries, without any banking or credit card systems the only technology that exists is a mobile phone.

Many of these countries rely almost entirely on services like "Western Union" to provide universal basic and not free money transfer and payments, western union is the practical "currency" in many countries.

Many developing countries have encouraged mobile phone companies to invest in infrastructure, the story of a home without any electricity, but with a solar charger for their mobile phone is not something unique today. Hence it is an obvious choice to base any global universally available payments system on this infrastructure.

Why the existing RTGS system is broken and cannot get anywhere close to FreeThe answer is obvious refer to the figure below, its nowhere close to KISS..

The Solution, Key Technologies

1. Hardware secured and protected ECDSA, and ECDH keys and key chain ( July 2015)
2. Secure Wallets on mobile devices (mostly available free today, just needs linkage to hardware key chain above).
3. Secure Private Block Chain Ledger (available today)
4. Secure Public Block Chain Ledger (available today)
5. Secure Identification Number(SIN) (complete infrastructure operational today)
6. SIN attributes for non anonymous  transactions (available today)
7. BYOD management for device compromise (available today)
8. BitAuth between key chain and mobile device ( available today)
9. Scaleable, algorithm agile eco-system (available today)
10. Payments protocol (in development)

A new and exciting word is almost here..

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 PBCL nodes within the PBCL's; hence the total processing of the PBCL is practically unlimited. The reference implementation also supported ~ 5,000 read operations, this asymmetry is typical of commercial databases.  The performance is relatively independent of the number of transactions in the distributed PBCL up to the tested 1 Billion transactions. Due to the decentralised nature of the PBCL, this poses no technical transaction processing limitations, and should easily exceed any existing global payments system.

All transactions within the PBCL are atomic, instantaneous and irreversible.

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 500 bytes per transaction

References
1. Free hardware generated and protected Bitcoin Private key and key-chain.
2. Identity Theft and the Digital World.
3. Triple Entry Accounting , and Block Chain Ledgers
4. BitAuth, Decentralized Authentication for the mobile 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.

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.