Blockchain Discussion Paper -...

Blockchain Discussion Paper

1

Kurt Wayenberg

Blockchain

Discussion

Paper


2

Kurt Wayenberg

TABLE OF CONTENTS

Table of contents ..................................................................................................................................... 2

Blockchain - Hype, innovation and make over ....................................................................................... 4

1 Blockchain - The hype is over ......................................................................................................... 4

2 Blockchain - The innovative part ..................................................................................................... 6

3 Blockchain - The make over ............................................................................................................ 9

3.1 Building Blocks ........................................................................................................................ 9

3.1.1 Hashing .............................................................................................................................. 9

3.1.2 Asymmetric Keys (Signing) ............................................................................................. 10

3.1.3 Chaining ........................................................................................................................... 11

3.2 Putting the pieces together ...................................................................................................... 12

3.2.1 Parties ............................................................................................................................... 12

3.2.2 Wallets ............................................................................................................................. 12

3.2.3 Transactions ..................................................................................................................... 13

3.2.4 BlockChains ..................................................................................................................... 14

3.2.5 Smart Contracts aka 'Batch Jobs' ..................................................................................... 15

3.2.6 to 'pay' or not to 'pay'........................................................................................................ 15

3.3 http://trueandauthenticated.com .............................................................................................. 16

3.3.1 Users ................................................................................................................................ 16

3.3.2 Parties ............................................................................................................................... 18

3.3.3 Wallets ............................................................................................................................. 19

3.3.4 Transactions ..................................................................................................................... 20

3.3.5 Full Example: The 'Kudos' use case ................................................................................. 21

3.3.6 Access via SOAP V1.1 XML (classical applications) ..................................................... 30

3.3.7 Access via JSON (mobile applications) ........................................................................... 30

3.4 Examples and use cases .......................................................................................................... 31

3.4.1 Livestock Traceability...................................................................................................... 31

3.4.2 Energy Companies ........................................................................................................... 33

3.4.3 Notary organizations ........................................................................................................ 34


3

Kurt Wayenberg

3.4.4 Voting .............................................................................................................................. 35

3.4.5 Fidelity points, Mileage, 'Hours used' and other cryptocurrencies .................................. 36

3.5 Some final design decisions .................................................................................................... 37

3.5.1 Anonymity ....................................................................................................................... 37

3.5.2 Privacy ............................................................................................................................. 37

3.5.3 The Distributed / Decentralized Autonomous Organization / Company ......................... 37

3.6 DXC.Portal Prototyping Platform ........................................................................................... 39

3.7 DXC.Portal Development Platform ........................................................................................ 40

3.8 .Net DXC Crypto-ledger: Value Proposition .......................................................................... 41

Appendix A: Additional documentation on ...................................................................................... 42

http://trueandauthenticated.com ........................................................................................................ 42

User Registration Process ............................................................................................................. 42

1 User registers and gets a blockchain account ......................................................................... 42

2 Upgrade the user account ....................................................................................................... 43

3 e-Mail Verify the account ...................................................................................................... 43

4 Advanced verification of the accounts ................................................................................... 44

5 Future extensions ................................................................................................................... 45

Appendix B - Asymmetric Key Pairs ............................................................................................... 46

John Doe Private key .................................................................................................................... 46

John Doe Public Key .................................................................................................................... 46

System public key ......................................................................................................................... 46

Jack Doe Public Key ..................................................................................................................... 46

Jack Doe Private Key .................................................................................................................... 46

Troy Private Key ........................................................................................................................... 47

6 Appendix C - Lorum Ipsum Text ................................................................................................... 48

Appendix D - Other Blockchain Solutions ....................................................................................... 49

IOTA ............................................................................................................................................. 49

IBM Blockchain ............................................................................................................................ 50

Corda ............................................................................................................................................. 50

JD.com .......................................................................................................................................... 50

Appendix E: Integrating Legacy Information Systems ..................................................................... 52

1 Making documents immutable ................................................................................................... 52

10.2 Making images immutable .................................................................................................... 54

10.3 Making data tables immutable .............................................................................................. 55


4

Kurt Wayenberg

BLOCKCHAIN - HYPE, INNOVATION AND MAKE

OVER

1 Blockchain - The hype is over

Blockchain has been the most hyped technology throughout 2016 and 2017. Although today, new

'blockchain vendors' still pop-up, and try to attract millions of dollars of investment money, the top of

the hype has been passed and, as Gartner predicted, the technology is sliding into the 'Through of

Disillusionment'. Online searches & tweets are dropping, governments are issuing restrictive

legislation, and communities get confronted with the many drawbacks of decentralizing control: lack

of accountability, problems with security, safety and privacy, sorrows with efficiency, ...

Ferdinando Ametrano, professor in Milano, was a bit too hopeful in predicting that 2017 would prove

that 'Blockchain' was a bad idea.

But today, March 2018, we are confronted with:

The lost illusion that one 'blockchain' would solve all business problems

The unreadable scientific documents full of mathematical explanations of questionable

algorithms that try to justify all kinds of new blockchain technology

The observation that the energy consumption is massive and completely unsustainable

as soon as blockchains grow from small to medium

The reflexion that nothing is more vailed than the crypto-platform's large initial wallets and

their owners, and this despite the 'transparency' claim

However, there definitely is some decent stuff in the whole hype and throwing it all away would be

incorrect...


5

Kurt Wayenberg

Unfortunately, the debate is very much burdened by the fact that a lot of secondary innovations are

included to promote solutions and best practices. These designs range from supporting tools in the phase

of 'ideation' or 'design thinking', over the support of 'proof of concepts’ & ‘rapid prototyping' , to full-

featured 'business configurations & workflow' development environments.

In this discussion paper, we stick to the essence of blockchain technology and try to unravel the knot of

expensive words and obscure technology to extract the innovations, albeit scarce but important...


6

Kurt Wayenberg

2 Blockchain - The innovative part

Blockchain has been called a 'game-changer'... And although it is, the statement was followed by an

endless list of 'benefits' and 'characteristics' that have nothing to do with blockchain. Let's cut the crap

and come to the core.

The uttermost important benefit of a 'blockchain' is that it is a 'System of Records' that is tamper resistant

and trustworthy

The impact of this benefit is that a 'blockchain' is de-facto answer to dispute-resolution.

All other 'components' can be considered as secondary benefits, as rather irrelevant features or even as

'smoke and mirrors' to fake importance. Let's discuss a few of these elements:

As secondary benefits, as rather irrelevant features or even as 'smoke and mirrors' to fake importance.

Let's discuss a few of these:

The 'Initial Coin Offerings' (ICO's) have some beauty in making the 'validation process' a bit

easier but they are by no means a necessity. On the contrary, these ICO's add scarcity to the

'product' and, as such, were an excellent trick to attract investments via crowdfunding ('Token

Sales'). Speculation, greed and the fear-of-missing-out, seed the sky-rocketing stock market

price. Always keep in mind that ICOs should represent an investment based on the existing or

new business an enterprise will generate. However this business model is often unclear and

not transparent, if there is a business model at all...

The 'Distributed Ownership' have some beauty in making communities less dependent from

one specific company, authority or organization. By thoughtlessly creating and maintaining

thousands of copies of the 'blockchain' database, we indeed have some reassurance that the

database might outlive some individual solutions but let us not underestimate the fact that

there always was a solitary 'foundation' or company controlling the code. Nor should we ever

forget that these financial models are never solid and always lead to a collapse if it keeps

growing

The 'Proof of Work' (POW) hashing has some beauty in that it requires more time to

reconstruct an alternative version of the blockchain, but for the rest POW is a weak argument

that never, ever will justify the inefficiencies of the POW.

The Ghost protocol in Ethereum (Greedy Heaviest Observed Subtree) is an ugly, overly

complex and entirely non-transparent attempt to overcome stale blocks and orphan

transactions. It also fails to avoid mining pool domination.

The 'Smart Contracts' are appealing because they can help implement some use cases on the

blockchain in a very fast manner. However, the concept is seriously flawed:

o Smart Contracts bring sloppiness, obscurity and non-transparancy to the blockchain,

which, from a governance point of view, is evolving blockchain to an opposite

direction of what it was designed for.

o Smart Contracts suffers from the same myopia than did early expert systems. Your

contracts need to have a view that reaches well beyond the current transaction details.

The trick they use is to open it up via an 'Oracle' but in an uncontrolled context the

combination 'Smart Contract' & 'Oracle' is nothing more than Pandorra's box...

o The validation of 'every transaction' in a trustless decentralized distributed blockchain

is extremely inefficient in terms of computing power. Whereas this process

theoretically still had some possibilities to exploit parallelism, however with the non-

transprancy of smart contracts this is completely impossible and today there is NO

parallelism in for example an EVM (Ethereum virtual machine).


7

Kurt Wayenberg

o Because of smart contracts Ethereum has created an overly complex transaction

payment scheme based on transaction complexity, gas price that users are willing to

offer to get their transactions executed first, and maximum-spent levels that is

completely lost when a transaction fails.

o In Ethereum you only can create a new 'cryptocurrency' (~ a seperate blockchain)

only via a smart contract. Why not via a standard transaction invocable by anyone

having the rights and / or funds to do so. What could be a possible reason? Other than

reserving this functionality to the creation of ICO's only?

o To my opinion most smart contracts are either in the category 'hello world' or are

supporting an 'ICO token' sales. I am not so sure it is as successful as it claims...

The use of the Digital Signature Algorithm (DSA) has some beauty in that it is a bit faster for

signature generation, but overall it is not really justifiable that this algorithm should be used

over the more secure and more successful RSA algorithm. DSA was the open source

alternative in the period that the RSA algorithm was patented. But today this algorithm is

freely available and by far the more widely used.

The blockchain addresses are most of the times a hash of the public key, made more readable

by clipping a part of it and/or by converting it to Base58 or Base32 and/or by adding a

(number of) check-digit (s) and/or by adding prefixes / suffixes. Despite all attempts to

improve better readability and decrease the manual errors, these approaches have limited

practical usage. In addition they open up a religious, decades old, debate, as to whether

primary keys should be intelligent (natural) or surrogate. To my opinion, most blockchain

keys today are the worst combination you can have: natural and unintelligent. The world

would be far better off with wallets and parties having more meaningful natural keys (IBAN

& BIC numbers, RRNs,...) or simpler surrogate keys (even a GUID is a relief compared to

these blockchain address). Also a combination of the two (party - natural key in combination

with a simple wallet surrogate key) can be a powerful option.

The wallet being fully anonymous and autonomous has its power, yet, in many situations an

explicit relation between parties and wallets might prove its superiority in permissioned

blockchains or in real business scenario's. At least both scenarios should be supported...

The required energy by the 'Proof of Work' and the massive distribution caused by the financial model

is what ultimately kills blockchain usage from a 'durability perspective'.

The massive up-front validation (aka the inefficiency of the 'distributed consensus') prohibiting swift

and immediate processing is what ultimatly killed it from a 'usability perpective'

The blockchain vendors already recognized these two points as the Achilles heel, and as a result are

making mining optional and are proposing alternatives for the distributed consensus. But hack - that is

85% of their code and whitepapers that can be flushed...

So the 'real innovation' is open and transparent, cryptographically secured, ledgers'

To be honest, even the degree of innovation is relative...The first (tax) ledgers were used in ancient

Egypt. The RSA algorithm dates from the seventies. The Secure Hash Algorithms (SHA-family) date

from the nineties (Hashing itself dates from the fifties). Even the 'chaining' (using hash codes) is not

new. Since 25 years, hash trees or 'Merkle trees' have been used, mostly to ensure that data blocks

transmitted from other peers in a peer-to-peer network are received undamaged and unaltered. So even

this incredible blockchain hype was more an evolution than an innovation.


8

Kurt Wayenberg

Nevertheless, blockchains in general and Bitcoin in particular, inspired the world, to bring data-

immutability (tampering resistance) and proof (dispute resolution) to the world of business transactions.

And that is the true innovation of this technology!

Today, it is time to be critical on the designs and to see how simpler and more transparent models are

more effective.

The big question is, will distributed DAPPS really break through? Well I think they do have some

usefulness, but their usage is quite limited. As already said, their number one usage remains

crowdfunding and attracting naive investors, but that area is going down. Other investment focusing

applications still our quite popular (????) There are a few message services of which no message never

ever can be deleted (voluntarily nor censored), and then there are a few basic games which never ever

leave the blockchain. Will distributed apps be attractive to business groups? They might if the people

in the group do not trust, nor cooperate, but the cost of ownership is significant ...

One of our main DXC colleagues focusing on Ethereum / Bitcoin like blockchains is Faisal Siddiqi

( [email protected] ) - feel free to contact him if you want to explore this route further.

My basic conviction is that none of the elements discussed in this section are of some importance in the

basics of blockchain technology: trust and immutability. You should disregard them and just live

without them and doing so probably makes your life easier... Just read-on and see what this approach

can do for you...


9

Kurt Wayenberg

3 Blockchain - The make over

A good programming practice is to refactor stuff rather than rebuild it. However, the coupling of

components and concepts in today’s blockchain implementations is so high that changes to a single

element cannot be isolated from the functioning of the system, nor from other components. The

technology stack is often polluted with all kind of 'other' innovative technologies (Swarm, IPFS,...)

which might help the implementation but do not add in the basics of the solution.

Probably the best strategy is tearing it down and than building it up after altering and improving some

flaws or design inefficiencies...

3.1 Building Blocks

When tearing it down you see we only get to 3 important building blocks: Hashing, Signing and

Chaining.

In this section we propose to use a standard hashing algorithm (SHA256), to use the widely used RSA-

asymmetric keys and we explain the principle of chaining

3.1.1 Hashing

The table underneath shows the essentials of hashing. We choose for a well-accepted SHA256 hashing

function and use BASE64 encryption.

https://approsto.com/sha-generator is a very nice online Hash calculator. The table shows the hashes as

if you were typing the sentence 'Hello World'.

The last hash is the hash for the Lorem Ipsum text (see the two pages in appendix).

47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=

H RL165g9Hj64QYeEadzn0uU0dr5F5gtM7b8igGmP4nCE=

He MO/ftS/2f4Dat8uJ3P4O7IQSlmz+WDJJk2dLRhbWvRE=

Hel t4nCTc22jEQ3sEwYa/I5pyB+dXP7GyKnSf4ae42W0pI=

Hell jVhvi2DfGtdQK1L8UNLgttDZtWQ4dcBU2CHf2OZnK+0=

Hello GF+NsyJx/iX1Yab8k4suJkMG7DBO2lGAB9F2SCY4GWk=

Hello World pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=

Lorem Ipsum C1IJ2yxejWJ1TQ5njR2HpLysVdEcCk56u8aqkj1xrh4=

The table illustrates nicely some characteristics of our SHA256 hashes:

All hashes are 44 bytes in BASE64 (256 bits = 32 bytes = 44 bytes in BASE64) irrespective

of the length of the hashed data

Even the slightest difference between two texts creates a completely different hash

Given a certain hash it is impossible to find the original text from the hash

https://approsto.com/sha-generator

1

0

Kurt Wayenberg

The same hash tests can be done on the DXC Signing Portal

(http://trueandauthenticated.com/portal/Encryption/Sign) but only for the SHA256 + BASE64

conversion. The portal also shows an additional nice technique that is very useful when criticists would

question the security of hashes or would utter the probability that multiple documents theoretically can

have the same hash. An alternative to moving to a higher hashing function in that case is generating the

hash for the inverse text extended with the length of the encrypted text (the RTPL hash = the 'Reversed

Text Plus Length' hash). This is like putting a double or even triple lock on top of your hashed text...

and although not mathematically proven probably will also assure no two documents share the same

hash + RTPL hash

3.1.2 Asymmetric Keys (Signing)

In RSA every person has a private key (for signing) and a public key (for other to check the signature).

The following scenario illustrates how it would work:

Example 1:

Suppose John Doe wants to borrow 100€ from Jane Doe and promises it to pay it back in 2019. He

could create the text:

I, John Doe, received 100€ from Jane Doe and I will pay it back in 2019

And he could sign it with his private key. This would give:

Lmawfae7EEMvx5zo59D9FCY0zMqAQwjt3vEeJh85lnZhmDbUAIdh0j88Y2fONznbt2Skzw

RYX/gkGA6qfbbTCgJW12Ds5P+1yFOTUuluSqTnYBAPSqINMjuVsxICtwCIofV8ByXuVw

s0fejn5DNC9uCeEaABV059OdgKV6gJRrw=

From now on John can never deny that he borrowed 100€, that it was to Jane Doe and that he will pay

it back in 2019. Anyone with a public key can check if indeed John did sign this transaction and the

transaction cannot be tampered with.

However, the requester is not the only one that can sign a transaction. The platform is aslo also a

candidate for signature usage !

Example 2:

Suppose John Doe sends this information to a ‘blockchain’ platform and suppose the blockchain

platform replies:

I, Blockchain platform, declared that I received, validated and processed the message < I, John

Doe, received 100€ from Jane Doe and I will pay it back in 2019 > signed as <

Lmawfae7EEMvx5zo59D9FCY0zMqAQwjt3vEeJh85lnZhmDbUAIdh0j88Y2fONznbt2Skzw

RYX/gkGA6qfbbTCgJW12Ds5P+1yFOTUuluSqTnYBAPSqINMjuVsxICtwCIofV8ByXuVw

s0fejn5DNC9uCeEaABV059OdgKV6gJRrw= > and I Inserted is as transaction number 1

Than the platform would sign it as:

lMwwIZ12cJpd12KOma9tup0XsEhLIFs0fslOE/z2ixpTRJQavf2GbtgpwHjXWBGQa8mwkxca

LC0aK9KFDAN4cGka9u4lUYGE9puORpVeJVv5Zp6y5sLzwhMZOZ73d4Pe7/svUcpMkTG

6/2vVIXlsnMckV/BT43PKJ/EP+TdD1NI=

http://trueandauthenticated.com/Portal/Encryption/Sign

1

1

Kurt Wayenberg

From now on the blockchain platform cannot deny anymore that it received the message, validated it,

processed it and added it to the database. Rather than receiving a classical 'your request number was

12345' you now receive a signature that proves your submission to the platform.

The blockchain platform also takes a hash from the previous transaction. That hash is:

0Xf1HyT9V6BdmVT7June09F0T5vvtMjstLImwivdbYY=

And we use it in the next section on 'chaining'

3.1.3 Chaining

Now suppose the blockchain platform receives another message, one from Jack Doe who also borrowed

money from Jane Doe. The received message was:

I, Jack Doe, received 80€ from Jane Doe and I will pay it back in 2020

And Jack signed it with his private key as follows:

A+9PJQOAXdCLDKjK22FSYpPe46dZBWun8Y2PBEfYZcovfkF/au5QzH7RokHWZs5vRS5

y6ue8ThkItxD1kDUapI/lGxrRF20f5U1gdy3C+6b0vucgD34LtoH1laTWg0VeSeKxuSJfte6x7

No92rI3Ux4F0xhONCFVcfl0S97ePZg=

Now as the platform calls itself a blockchain platform it cannot ignore the obligation to chain the

transaction. The platform now answers:

I, Blockchainplatform, declared that I received, validated and processed the message < I, Jack

Doe, received 80€ from Jane Doe and I will pay it back in 2020 > signed as <

A+9PJQOAXdCLDKjK22FSYpPe46dZBWun8Y2PBEfYZcovfkF/au5QzH7RokHWZs5vRS5

y6ue8ThkItxD1kDUapI/lGxrRF20f5U1gdy3C+6b0vucgD34LtoH1laTWg0VeSeKxuSJfte6x7

No92rI3Ux4F0xhONCFVcfl0S97ePZg= > and I Inserted is as transaction number 2, chaining it

to record 1 with hash < nmk8Ggv15rx0p5bYwFxPd5DZqqN9KVw3aLtYRsWcIkU >

And signs this message as

e3/jb5W5nNFJSZrYEUR+Aj+/94PiWooGgUQc3yurW9QgQ38reCuq1VQdEspuXaT7XHR9L

EMdxpw2jitXX4cqVUPIdevDsc1SHkyCpj0cw7CC8KJ4GqF2Wjz0KLWSUwb2yqyPgP7LA

FtIi8iWvolsE3KBfAyVhxPJPUlrKdQ8z8E=

What has happened now? The transactions are 'chained' together !!!

Not only are transactions 1 and 2 immutable. They are also linked together and as such the platform can

not alter the transaction number nor the transaction sequence in time. Nor can it add a transaction in-

between. The whole ledger has become 'immutable'

We will add some structure into the transactions later, but the principle should be clear

You can play around with signing and hashing using

http://trueandauthenticated.com/portal/Encryption/AsymmetricKey


1

2

Kurt Wayenberg

3.2 Putting the pieces together

And that's it - those are the basic ingredients to set-up a blockchain. We will now build up a new and

simple 'blockchain' or better a 'cryptographically secured ledger'. And we focus on integrating it with

current systems and business processes.

We will bring a bit of structure in managing the data and the signatures

And we will focus on integrating it with current systems and business processes.

But at first, we want to do some explicit modeling of the relations between parties and wallets. We also

will discuss whether or not to give up some anonymousness at the benefit of more usability and user-

friendliness...

3.2.1 Parties

If we learned something over the past 50 years in IT it is that the cornerstone of many systems is the

central party file. For organizations this has the form of a central customer file and a list of the business

partners. For government authorities the list is made up of citizens and registered companies. In the

blockchain and bitcoin community there were no formal parties. Only wallets. However, with every

transaction some of the identity is revealed as the sender of a transaction (hopefully) knows to whom

he sends some currency...

Party design principles that should be recommended to service provider and platform designers:

1. Put parties in the center of your registration process

2. Give parties a rich identity, a free string, even allow GUIDs (nvarchar 38)

3. Give parties a color code for easy recognition

4. Give parties a a QR code for easy administration

5. Allow multiple wallets to be attached to a single party

6. Rather than attaching private keys to wallets, attach private keys to parties and allow a party

to use his central key to sign transactions (at least by default)

7. Link user registration to 'new blockchain party' creation (at least by default as it should

also be possible to have multiple logons per party / company)

8. Decide on how anonymous a user can remain and decide on how to maintain its status:

Completely anonymous? email verified? SMS-verified? Confirmed by commercial

organization? Confirmed by institution? Self-checked?

9. Confirm transactions by emailing the inserted transaction to the party, together with a 'signed'

receipt

10. Creation of a party is a standard transaction on the blockchain.

11. On publishing a party, its public key gets published too

12. On publishing a party, the party gets automatically assigned a transaction balance wallet

13. A party is validated when all its wallets on the blockchain are validated. Keep track of its last

validation date-time.

3.2.2 Wallets

Wallets are the cornerstone of any blockchain. They are the address from and to an amount of currency

or information is transferred.


1

3

Kurt Wayenberg

How to validate the wallets is open to much debate. Pure blockchain validation (BitCoin) requires

redoing all transactions in order to determine the balance. Others (like Ethereum) store intermediate

state allowing for faster recalculation. The state, continuously changing, is maintained at the expense

of significant amounts of storage.

Wallet design principles that should be recommended to service provider and platform designers:

1. A wallet is attached to a party and this relation will never change

2. A wallet is attached to a blockchain and this relation will never change

3. A wallet is attached to the blockchain currency and this relation will never change. This is

important for managing assets.

4. Give wallets a rich identity, a free string, even allow GUIDs (nvarchar 38)

5. Give wallets a color code for easy recognition

6. Give wallets a a QR code for easy administration

7. By default keys are assigned to parties but when a seperate key is kept on the wallet, this key

must be used to sign transactions

8. All the transactions need to be signed using the (sending) party / wallet key (exception:

transaction administration and payments; these are added by the platform)

9. Keep a balance on the wallet

10. Creation of a wallet is a standard transaction on the blockchain

11. On publishing a new wallet, the 'owning' party and the linked 'blockchain' are also published.

12. A wallet is validated when all its wallets on the blockchain are validated. Keep track of its last

validation date-time.

3.2.3 Transactions

Transactions are the essence of any transaction system and as such of blockchains too.

The difference with these blockchain transactions is the usage of the hashing, the signing and the

chaining!

Transaction design principles that should be recommended to service provider and platform designers:

1. The transaction adds owning party, owning wallet, target party and target wallet, blockchain,

currency and amount as basic info (whenever relevant)

2. Every transaction keeps an owner reference which is a unique identifier for the owning party

and prevents double booking

3. Every transaction is chained to the previous one. The transactions maintain their 'location' in

the chain on three levels: platform-sequence, blockchain-sequence and owner (=party)

sequence. Because wallets are optional, do not maintain a wallet transaction sequence.

4. A transaction creating a new blockchain only specifies owning party, target wallet and target

currency

5. A transaction creating a new party is done by the System Account (either by self registration

or by a platform administrator)

6. A transaction adding information to the blockchain does only need a party, yet can specify

two parties as well as two wallets

7. A transaction transferring currencies always specifies both wallets as well as both parties

8. A transaction can never specify a negative value

9. A transaction cannot result in an overspent wallet

10. A transaction keeps a copy of the request and the requests signature

11. The request can be minimally specified (e;g. wallets only when transferring currency,

blockchain referred without currency)

1

4

Kurt Wayenberg

12. The request however needs to specify a date-time and this datetime cannot deviate

significantly from the platform's datetime or else the transaction fails

13. The datetimes of the transaction are the date times assigned by the platform, not the date time

specified in the request

14. A transaction is linked to the previous via a standard hash as well as a RTPL-hash

15. The transaction hash and RTPL-hash always include a transaction hash + an RTPL-hash of

the stored information too. When no stored information is added, use the hash string

VKkJezNPsTj7+V5/HI3ZhZQQQThRfVW6HLKqp7xgpP0= for the empty string and the

RTPL-string 29W2sjbS2If7cI/lJ2DYuuwhyANbrQRrLbtiUem/SJY= for the empty (0 length)

RTPL string

16. The transaction base description is also added to the database so everyone can easily verify

the hash at any time

17. For every transaction a transaction result out is created in the form:

<blockchainplatformsequence>-<blockchainsequence>-<ownersequence>:<transactionhash>-

<RTPL transactionhash>. By communicating this result, the platform basically recognizes the

transaction's existence, defines its exact position in the chain, makes all these transactions

immutable, and confirms their linking

3.2.4 BlockChains

As already discussed above. The illusion of 'one global blockchain' is completely dissolving. The open

question is what products will remain and in what form will they implement all kinds of use cases. The

only certainty is that there will be a lot of 'blockchains'

Countries will store there identity records in governmental ledgers

Assets and (notary) contracts will be stored by notary groups

Frequent flyer miles and other fidelity cards will be stored in the ledgers of the companies

issuing them

Et cetera for voting rights, energy/water/gas/ consumption, stock positions, energy

production, passages over toll-roads, our certificates / degrees / accomplishments / kudos /

contracts, jobs, paid taxes & social security, orders and deliveries, reservations

And in some cases transactions (or transaction summaries or transaction extracts) might be replicated

in multiple ledgers. e.g.

Countries might store (certain?) identity records also in pan-european or global ledgers,

Assets and (notary) contract summaries might also be stored on notary association ledgers or

government ledgers. ,

Frequent flyer miles and other fidelity cards might be of interest to industry groups

Et cetera for voting rights, energy/water/gas/ consumption, stock positions, energy

production, passages over toll-roads, our certificates / degrees / accomplishments / kudos /

contracts, jobs, paid taxes & social security, orders and deliveries, reservations

Blockchain design principles that should be recommended to service provider and platform designers:

1. Allow for multiple blockchains on your service platform

2. Give a lot of freedom in naming different blockchain, even GUIDS (nvarchar 38)

3. Assign an owner (party) to a blockchain

4. Assign (optionally) a payment blockchain and a payment schedule so that users of the

platform will need to pay a certain amount of cryptocurrency for every transaction they do. In

my opinion a transaction price should be fair, constant, deterministic and identical perhaps

with some variation on the type of transaction.


1

5

Kurt Wayenberg

5. Allow any party in the system (with the proper rights / funds) to create a blockchain

6. Allow (optionally) to assign a payment schedule so that users of this blockchain have to pay a

certain amount of cryptocurrency for every transaction they do. This can be used to back up

the transactional payment for platform usage

7. Link a wallet to one and only one blockchain

8. Only allow transactions between wallets on the same blockchain

9. Define a blockchain as either fluid or discrete ( for currency-like transactions respectivey

assets)

10. For fluid blockchains there is only 1 currency (the name is syntactic sugar) and wallets can

transfer anything between 0.00000001and 1000000000) to one another

11. For discrete blockchains the 'asset' is the currency and a wallet can either contain the

asset with an amount of 1.0) or not (amount of 0.0) by nature of the blockchain technology an

asset will also be posessed by one and only one wallet

12. Allow any blockchain to receive information posts as information

13. Creation of a new blockchain is a standard transaction on the blockchain

14. On publishing the new blockchain also publish the 'costing scheme'

15. A blockchain is validated when all transactions on the blockchain are validated. Keep track of

its last validation date-time.

3.2.5 Smart Contracts aka 'Batch Jobs'

I already criticized the sub-standard scripting environment like technology such as Solidity or other

'smart contract' technology.

In my opinion good old batch jobs can do a perfect job in this in that:

They can run online just on top of your blockchain

You can exploit good basic techniques like adding multiple transactions in one 'technical'

transaction

You don't need Oracles

What batch jobs however have to learn from 'smart contracts', is that they should be set-up in a sense

that it is easier and faster to add new logic... But that is just a matter of architecture and creativity. You

do not need 'Solidity' or other ill-designed, bug sensitive, scripting languages

3.2.6 to 'pay' or not to 'pay'

We already discussed the technique and process where one optionally account for transactions on the

blockchain. An advantage of 'accounting' for transactions is that Denial of Service attacks are either a

lot less effective or else a lot more expensive to conduct for attackers


1

6

Kurt Wayenberg

3.3 http://trueandauthenticated.com

Meet our crypto-ledger platform 'True And Authenticated' platform. So far it still is a 'discussion' and

'try-out' platform. But it is very successful in its purpose.

At the end there are some suggestions on how to get your use cases entered via manual registration or

via upload using Excel.

When facing issues please contact [email protected]. When having questions on how to

optimally model your use case please contact [email protected].

3.3.1 Users

The simplest way of getting started is by using one of our test users.

The full experience obviously comes with self-registration

3.3.1.1 Test-users

To use a test user, use the following steps:

Open a browser and go to http://trueandauthenticated.com

Click LogOn

Enter a user name. There are 31 users to pick from. Use the n'th user where n = your birthday

- day index.

o Mike Mukesh Amy David Sachin

o Mariano Peter Manoj Meg Robert

o Skreekanth Pierre Marilyn Bill Michael

o Eric Stephen Howard Dan Maruf

o Jo Seelan Eugene Troy Art

o Kurt Nick Sven Erich Nicolas

o Gijs

Enter the password. All test users have the same password:

o DXC.R0CK5 (with a zero)

mailto:[email protected]


1

7

Kurt Wayenberg

You are now in the trueandauthenticated application

3.3.1.2 Self-registration

Appendix A, chapter 1 gives some details on how to self-register yourself on the new platform

The basic steps are very straightforward:

Go to http://trueandauthenticated.com

Cick on the Register link

Enter your data

Submit

An email validation email is sent and after clicking on it, your account will be upgraded to an

'email verified' account.

You now are a registered user, and a blockchain party was automatically created.

When doing self-registration and a valid email was available, there are some advanced steps that might

be of interest that more or less catapults you directly in the blockchain discussion: You can fill in your

basic information (Address information) and then publish it in combination e.g. with your SSN/RRN id


1

8

Kurt Wayenberg

or your driver’s license and then publish it in the blockchain. You now can prove that you are (linked

with) this account.

The steps are:

Open your profile (link on top or via menu)Complete your address data

Enter your address information

Enter your SSN/RRN id or your driver’s license

Save your information

When now checking your SSN/RRN or drivers license information there are some options to

put this information on the encrypted ledger.

Submit both of them

Use the hashing tool to verify your information hash and understand why the hashing is an

adequate proof that you own this information

3.3.2 Parties

By clicking on My Blockchain Party (on the main menu) the party information window opens

This gives you access to the party info (1), the wallets (2) and the encryption keys(3)

3.3.2.1 Searching Parties

To see other parties, one just clicks the 'search blockchain party' information

Another possibility is to just paste the following JSON call in a browser


1

9

Kurt Wayenberg

http://trueandauthenticated.com/portal/Api/FlexibleReporting/RPT6702?Identity=&SecurityToken=G

Bc6CT4lPdMiOVCYdOvMbsrH2nuRQ3pSrf1iaM7A8aM%3D

The JSON call allows to get all this data in an electronic form. It is also quite handy to be viewed in a

Firefox browser....

At this moment, we .allow all users to view all party (and wallet) information in the system. Obviously,

by using permissions the access can be more limited.

3.3.2.2 Setting the party's mail address

There are 2 pieces of Party information for which an update can be interesting.

By adding a mail address, you get a confirmation by email on every transaction done by this Party

You can also clear the security kays keys and add your own keys. Or you can just enter your public key

while keeping your private key 'private'. This is interesting especially if you use the application out of

your own application (using SOAP) or via your smartphone application (using JSON-services), but you

can at every submit add sign the transaction yourself

3.3.2.3 Looking at My-Party

Inspecting your 'Party' information is straightforward:

Go to the main menu

Click 'My Blockchain Party'

You can now see:

o your party identification

o the QR-code

o the default wallet for 'paying' transactions (currently new parties get by default a

budget of '500' worth of transactions)

o your other wallets (if available)

o your public and private key

3.3.3 Wallets

To see your wallets, just clicks the 'my Party' link

There is no online screen to see all wallets. However, searching for a specific wallet is possible via the

Search Party screen. This retrieves you the owning party. In its wallet overview you than should see the

wallet you are looking for.

One possibility to get access to all wallets is to just paste the following JSON call in a browser

http://trueandauthenticated.com/portal/Api/FlexibleReporting/RPT6703?BlockChainCode=&Currenc

yCode=&PartyIdentity=&WalletIdentity=&SecurityToken=ssIVBUoHyR5SFf32IsUeq4iPH11GVJxn

hXiF%2BHM%2FLFI%3D

http://trueandauthenticated.com/portal/Api/FlexibleReporting/RPT6702?Identity=&SecurityToken=GBc6CT4lPdMiOVCYdOvMbsrH2nuRQ3pSrf1iaM7A8aM%3D

http://trueandauthenticated.com/portal/Api/FlexibleReporting/RPT6702?Identity=&SecurityToken=GBc6CT4lPdMiOVCYdOvMbsrH2nuRQ3pSrf1iaM7A8aM%3D

http://trueandauthenticated.com/portal/Api/FlexibleReporting/RPT6703?BlockChainCode=&CurrencyCode=&PartyIdentity=&WalletIdentity=&SecurityToken=ssIVBUoHyR5SFf32IsUeq4iPH11GVJxnhXiF%2BHM%2FLFI%3D




2

0

Kurt Wayenberg

The JSON call allows to get all this data in an electronic form. It is also quite handy to be viewed in a

Firefox browser....

At this moment, we allow all users to view all wallet information in the system. Obviously, by using

permissions the access can be more limited.

3.3.4 Transactions

Transactions are the essence of our cryptographic ledger

The type of transactions are

Blockchain creations (Blockchains for assets, for currencies or for registration

Party creations

Wallet creations and initial balances

Registering text (public or private)

Transferring currencies or assets

Depending on the transaction type, the transaction defines owning party, owning wallet, target party

and target wallet, blockchain, currency and amount as basic info. The schema underneath details the

possible combinations

Creating a transaction is just a matter of filling in the corresponding fields.


2

1

Kurt Wayenberg

When submitting the transaction, it has to be signed by the owner's private key. In that way nobody can

dispute it's content, nor its initiator.

When adding the transaction to the database it is linked to the previous transaction,

The inserted transaction (location + transaction hash) is returned to the submittor thereby giving the

submitter a proof of submission that the platform will never be able to deny.

3.3.5 Full Example: The 'Kudos' use case

The best way to get a clear understanding on how it all comes together, we explain a simple but very

nice use case. The use case was defined by Mariano Silva (Chile) ([email protected]). He

presented his idea on our global DXC-blockchain community (to join this community contact

[email protected] - US)

Mariano Silva had a full range of suggestions but basically speaking it boils down to the following

simple process:

Employees get a number kudos

When employees are happy with some service, they send a colleague a number of kudos to

thank him

Your balance of received kudos is used to pay out some financial reward

This process of gamification of commitment, motivation and remuneration should be yearly

repeatable

Let's see how we can capture a great part of this use case in a crypto ledger solution using our portal

solution. The use case is uploaded so it can be easily expected online.

3.3.5.1 Step 1 Create the blockchain

The person creating the blockchain is the administrator for the blockchain.

As such Mariano is the one that should create the BlockChain.

The transaction underneath is the way how the Kudos blockchain is created.

The XML representing this transaction is as follows:




2

2

Kurt Wayenberg

After submitting the transaction, the blockchain is created!

3.3.5.2 Step 2 Create the Wallets & set the initial balances

Mariano now creates a wallet for every other person.

In the transaction underneath Mariano is initializing a new wallet for Mike and initializes it to 100

kudos:


And this is repeated for every person

For a better administration it is better to assign a different wallet for receiving the kudos. So Mariano

just repeats the same exercise and gives each person an extra wallet yet with a zero balance

3.3.5.3 Step 3 Creating transactions

Every one can now send Kudos.

In real life we would avoid working with the complex identities and we would hide them behind some

meaningful names. In the test application we added some 'friendly names' to the identities for kudoo

blockchain, parties and wallets.


2

3

Kurt Wayenberg

The example underneath shows the transaction where Kurt sends over 5 Kudos to Meg


When entering the transaction, it get signed:

With each entry in the ledger, a confirmation email is delivered too:


2

4

Kurt Wayenberg

3.3.5.4 Step 4 Checking the balances

You can check your party and its wallets. Every wallet shows the balance.

Via search party one can access other parties and wallets.

Another way to access the parties and the wallets is by just clicking the parties in the

transaction overview

3.3.5.5 Step 5 Checking the transaction

You can now go to an overview of the transactions and open the last transaction that is added.

All detail of the transaction can be verified: The owner-info, the target info, the request and its signature.


2

5

Kurt Wayenberg

An interesting tab is the chaining tab (see above)

It shows:

The hash (and RTPL hash) of the previous transaction

The summary of this transaction containing

o The previous hashes

o The transaction data

The newly created hash (and RTPL hash) effectively linking both transactions

The proof info is the result delivered by the platform. The first part is the sequence information of the

inserted transaction (nth Tx on the platform, n2th Tx on the blockchain, n3th Tx by the owner) and the

hashes.


2

6

Kurt Wayenberg

The second part is the signature of this result

3.3.5.6 Explicit Signing

In the section on blockchain parties it was shown that each party had both a publik key and a private

key. The private key was stored in the database (in an encrypted form) and all signing was 'implicit',

meaning that the platform took the party's key for signing transactions.

Now consider user Troy. He does not keep his private chain in the application. If he tries to submit a

transaction he gets the error:

Parameter User Block Chain Party is not specified Please enter private key pair or sign the data

yourself

And he gets presented a screen where he can either put its private key in (the key is used for signing and

not stored in the platform) or he can sign himself (either as described further in the paper or by just

using the signing functionality

For example via the sign-functionality:


2

7

Kurt Wayenberg

Obviously, when you do not store your 'private key' in the application (out of principle, or

because you do not trust the system, or for whatever reason), you should not pass it to the

system either to help you with signing. Instead you should use some commercial or own-

developed application (as long as it is trusted) to sign your transaction, and then you only

should pass the signature.

The code underneath lists the 'signing' code. It can be freely integrated in your own applications

Integrating it into your applications can be done via a number of channels. The 2 most important

ones are via SOAP 1.1 and via JSON (Java Script Object Notation).

SOAP 1.1 is particularly popular in integration with classical platforms.

JSON is especially popular for integrating mobile applications. Karl Verstraelen (Belgium) dDid an

end-to-end integration-POC with the platform on a mobile application. The essentials of his

solution are:

Private key is kept and stored on the smart phone

The signing is done on the smartphone more or less as described with the signing code above

Submitting the transaction is done over JSON.


2

8

Kurt Wayenberg

The POC was created with XAMARIN forms. A few screen shots can be found underneath:

Another technique that can be used are XML streaming but this approach is not dicussed in this paper.

3.3.5.7 Conclusion

So do blockchains then fix it all?

Well, it should be clear that blockchain-like platforms are a very nice solution to get

currency-transfer-like use cases up and running quite fast. At the same time data

immutability is added to the register leading to an out-of-the-box realization of

dispute resolution.

However, we still need business rules and application

intelligence especially when your concept turns into a real process.

Suppose we start to give 'financial benefits' based on the kudos in your wallet and how

well one participates....


2

9

Kurt Wayenberg

That might trigger unwanted behavior which should be managed, either in the application or

in the process. i.e.

What if people grant them selves their kudos?

What if people / teams start ping-pong-ing (resending) kudos to one another? It might

not affect the balance but the team might get kudos because they send so many

kudos...

What if people accidentically use their received kudos rather than their kudos for

sending?

Is it ok that someone transfers all his kudos to someone else and ask that person to be

Santa Claus?

etc...

As said, you get a jumpstart, but you still need to make it a real application


3

0

Kurt Wayenberg

3.3.6 Access via SOAP V1.1 XML (classical applications)

For integration over SOAP 1.1 you need to discover the structure using the Web Service

Description Language (wsdl) describing the web service defined at:

SOAP http://trueandauthenticated.com/DXC_Portal_WebServices/PortalServices.asmx

Once you created the stubs in your application and you created the string to be signed the code is pretty

straightforward:

3.3.7 Access via JSON (mobile applications)

For integration via JSON, you need to start from the web api at:

JSON http://trueandauthenticated.com/portal/Api/PortalBlockChainSOAP

http://trueandauthenticated.com/DXC_Portal_WebServices/PortalServices.asmx

Once you created the string to be signed the code is pretty straightforward too:


3

1

Kurt Wayenberg

3.4 Examples and use cases

The previous chapter discussed in quite some detail a typical example of transfer of crypto currencies.

There are lots of other use cases imaginable. In this section we discuss a number of them. Livestock

management, Energy companies, Notary organizations, Voting,...

We do have available an extensive use case around payments and around integrating payment

information crossing different 'ledgers' but discussing this one in detail is deemed inappropriate for

this discussion paper.

3.4.1 Livestock Traceability

A possible way to set-up a cryptographically secured ledger could be as follows. Remark that any

similarity with an existing, good working system is purely coincidental.

3.4.1.1 Parties

A prerequisite in getting good traceability is defining all players in the food chain. i.e. all organizations

and their roles in the food chain. This role can be all kind of roles like farmer, dealer, cattle assembly

place, transporter, market, and slaughterhouse

Suppose we give all parties a Party-Identity and a key-pair. Whether or not we maintain a company

'profile' in the blockchain or in our classical applications is for now irrelevant.

Let's give the parties an identity like CC1234567X with CC a country prefix, 1234567 a number

identifying the party and X a control digit to avoid manual errors

3.4.1.2 Moving individually tagged Livestock around

In Europe all Bovines are individually tagged and we can reuse their earmark identifications. Their

structure is CCX123456789012 with CC a country prefix, 123456789012 a number identifying the

animal and X a control digit to avoid manual errors

3.4.1.2.1 Ownership

We set-up an asset Blockchain with each 'Animal' as a possible 'Asset' (currency). Every farmer receives

for every owned animal a wallet on the Bovine ledger with as asset (currency) the owned asset.

A 'transfer' of an animal ownership can now be easily done by transferring the asset to the new owner

(another farmer)

Advantages for the food chain:

The ownership of an animal is at al moments crystal clear and cannot be claimed nor denied

As part of the standard receivable process information of the transfer is confirmed by mail

If the current owner does not wish to finalize the administration he can give the private key of

the animal wallet to the new owner so that this one can do it himself, probably as fast as

possible as you never know who else receives the private key

The animal ownership history in time is transparent and it is guaranteed that the information

has never been tampered with.


3

2

Kurt Wayenberg

There is no dispute possible whether the mentioned events / actions have been taken place in

the specified form on the specified date

3.4.1.2.2 Whereabouts

Whereabouts are a bit more difficult to organize. One could set up a complex scheme of wallets but as

whereabouts information is less formal one might consider to just set-up some information scheme. e.g.

We set-up an Animal Information Blockchain, this time with each 'Animal' as a possible 'Wallet'. Every

party registers the whereabouts of this animal depending on his role. The ledger for animal

CCX123456789012 might look like

PARTY DATE EVENT

FARMER1 DATE2 OUT

FARMER1 DATE1 BORN

FARMER2 DATE3 IN

FARMER3 DATE4 IN

FARMER2 DATE5 OUT

MARKET1 DATE6 IN

MARKET1 DATE6 OUT

SLAUGHTERHOUSE1 DATE7 IN

This information approach can be extended to various other approaches. I;e. Registration of other

animal information like:

Veterinary actions

Diseases

Inspections

Slaughtering observations

...

The advantages for the food-chain are:

Complete traceability where an animal has been

All information at a glance

The actions might serve as formal reminders of batch process actions that need to be

taken The animal ownership history in time is transparent and it is guaranteed that the information

has never been tampered with



3.4.1.2.3 Import / Export

In fact the platform scales perfectly to any chosen level

1. One blockchain used by all countries in the food chain

2. One blockchain used by a number of countries in the food chain

3. One blockchain per country


3

3

Kurt Wayenberg

4. One blockchain per region

Obviously in cases 1 & 2, it is clear that either one of the countries or otherwise an independent platform

provider needs to host the blockchain for a defined period of time

In cases 1, 2 and 3 some clear arrangements need to be made for import and export of animals and the

equivalent transfer / sharing of these animals


Imports and Exports totals as well as details open and transparent

Information can be trusted and has not been tampered with



3.4.1.3 Moving herds around

Tracing herds is a bit different than tracing individual animals yet there is a lot of similarity

Per type of animals (goats, sheep, pig, ,...) a blockchain is setup. Every party keeping herds of this type

of animal receive a wallet initialized with the initial count of the numbers of animals. Once the

blockchain is initialized, the business as usual state can be achived:

Numbers of animals that are moved to a herd of another party are simply registered

New-born 'notifications' or population 'adjustments' make sure the number of animals in the

chain is tracked.

Information as above (veterinary actions, diseases, inspections and slaughtering observations

can be easily added on the herd wallet


All animal numbers in and out are tracked

Running totals of the newborns still can be verified based on earmarks

Whereabouts of (parts of) the herd are visible at any moment in time

Special 'quality meat' can be traced that livestock is only traded between parties having that

special label

Animal movements and information is transparent and it is guaranteed that the information

has never been tampered with



All information readily available at a glance

3.4.2 Energy Companies

Energy companies have a few challenges today. Especially with green-energy certificates, solar panels,

group-investments, et cetera, some interesting developments take place

Crypto ledgers can again be of great help here.

This is how it could be set-up on the consumer side:


3

4

Kurt Wayenberg

Every energy supplier has a blockchain to measure the consumption

Every period (15 minutes? hourly? daily? weekly? monthly?) the consumption is registered

Every period (15 minutes? hourly? daily? weekly? monthly?) the production of solar panels is

registered

Per group investment (set of solar panels) a blockchain is set-up

The blockchain defines the percentages how the gains should be divided

A simple batch job takes the periodic production result and distributes the green certificates

pro-rata to the 'owners'

Advantages for the energy market

At any moment in time full transparency is offered about how production of the solar panels

are distributed to the stakeholders

Green certificates can be transferred (sold) to other persons/wallets opening up a new

produced energy market

Participation can be altered as apartment owners transfer their part to new apartment owners,

or others.



This is how it could be set-up on the producer side:

Every energy distributor has a blockchain to project its expected consumption. They have one

wallet for every 15 minutes. And this for today, day+1, day+2, next days in week, next-days

in month(s)

Energy suppliers can offer their production volumes at a certain price

Contracts are formally accepted

Every period (15 minutes? hourly? daily? weekly? monthly?) the consumption is registered

Every period (15 minutes? hourly? daily? weekly? monthly?) the promised production is

registered

Every period (15 minutes? hourly? daily? weekly? monthly?) the realized production is

registered

A simple batch job takes the periodic production result and creates invoice-read summary

records.

Advantages for the energy market

At any moment in time full transparency is offered (to people who have access to the data) in

any status (projected, delivered, invoiced)



3.4.3 Notary organizations

Without any doubt, the impact of blockchain probably on this market will be dramatically. For

document-based administration (testaments, patents, certificates, degrees, job-history ...) the set-up is

straightforward:

Set-up a blockchain

Publish Texts and/or hashes of text

Optionally include person references in your content*


3

5

Kurt Wayenberg

Optionally have impacted persons confirm the content*

Advantages for the community:

Basically any person can put a piece of text in the blockchain

Adding it to the ledger makes its content immutable

Adding it to the ledger also sets its timing correct

The signature makes it clear; it is signed by the issuer and hence indisputable

Taking a hash from an image (ppt) and adding the hash into the ledger makes the image

immutable

Taking the hash of a set of legacy-db-records and adding the hash into the ledger makes the

set of legacy records immutable

For asset-management the basic set-up is slightly more complicated, yet it remains easy to manage

Define a blockchain with a 'currency' for every asset

Define the persons and their identities*

Assign a wallet with the asset as currency and a quantity of 1.0

Asset transfers is just a matter of transferring the asset to another party

The owner of the blockchain is the one introducing new assets if needed o

The owner of the blockchain is also the one intervening (e.g. how do you transfer a house

when the owner died).


The community can self-manage its assets and asset transfers

Ownership is clear at all times, ownership trails are visible by default



* By far, identity management and key management, remain the cornerstones of any ledger solution

3.4.4 Voting

Voting and Elections

In essence this is a dream-use-case for cryptocurrency albeit that some tricks are needed to guarantee

the privacy on who voted for who.

First the basics:

Blockchains are set up for every 'election' (i.e. a blockchain for each local election on city

level up to 1 blockchain for e.g. the European elections

Each 'party' is a party in the system and per 'election' receives a wallet for the party in general

and/ or for each electable person in particular

Every citizen receives a voting wallet for each election in which it is allowed to participate

Every citizen can now place it's vote



3

6

Kurt Wayenberg

Every citizen has one vote, and one vote only in each selection he can participate in.

Out of the box blockchain behavior would be that he can give to transfer this vote to 1 wallet

or to multiple wallets (even over the different parties). Probably some business rules will be

necessary to make choices between the wallets

All votes are non-disputable

It is clear who has not voted

The results cannot be disputed

The problem with the basic set-up is that the voting is not private. Everyone can see who voted for who

In order to fix this. It is necessary to do some extra steps. The choice is whether or not you 'hide' the

election result (encrypt it) but keep full traceability or whether you take some more drastic actions to

maintain the privacy with the risk that e.g. the 'traceability' / 'guarantee' has some holes. Techniques

are:

Encrypting the voting results and inserting them with a hashed key in a format which apart

from a period indication has no time available indicating when a certain vote has been added

so it cannot be linked to the voter

Every 10 minutes the available votes of that past set of 10 minutes is cryptographically

signed. The ledger now is immutable again.

The time in between has a potential for tampering on a selective set of votes for a selective

amount of time but that is the price for privacy

3.4.5 Fidelity points, Mileage, 'Hours used' and other cryptocurrencies

Cryptocurrencies are very natural use cases. Any 'measurement' can serve as cryptocurrency 'valuta'

ranging from hours parked, material consumed, to fidelity points earned or kudos given to other

colleagues

The set-up again is basic and simple

A blockchain for the cryptocurrency

The involved parties and their identity

A wallet for the owning parties initialized with an initial balance

Transactions are but a transfer of a certain amount of currency from one wallet to another

Advantages for the community

The community can self manage its wallets

currencies, kudos, fidelity points by default also can be freely transferred to other persons

(e.g. to relatives)

There is no dispute possible whether the mentioned events / transfers have been taken place in


Balances and totals visible at any time


3

7

Kurt Wayenberg

3.5 Some final design decisions

3.5.1 Anonymity

A new account is created by self-registration or by a platform administrator. There is currently a lot of

freedom and it might be sometimes difficult to balance between anonimity and privacy. We do think

this point should be looked at on an application level.

3.5.2 Privacy

As discussed in the previous section, it might be sometimes difficult to balance between anonimity with

privacy. As sayd, we do think this point should be looked at on an application level. In addition, there

is the GDPR guideline to be conform with. The GDPR guidelines as followed in this application can be

consulted via this

link: http://trueandauthenticated.com/Portal/nl/Information/Content/DATA%7CGDPR

3.5.3 The Distributed / Decentralized Autonomous Organization / Company

Until recently, the idea lived that one 'blockchain' would solve all business problems, and that everyone

would participate, yet that no one would be the ‘owner’ of the blockchain. This bubble of the distributed

autonomous corporation / decentralized autonomous organization is splashing. Where is the concepts

failing?

Besides the negative ecological impact of the economic model/mining and the impracticality

of distributed consensus, the simple distributing, sharing & storing of data over the

blockchain nodes has hit multiple technical boundaries, making the concept unworkable and

also terribly expensive from a total cost of ownership (hardware, software plus technical staff

and administrators)

The solution is very hard to scale. End of 2017 the total size of the top 3 blockchains (Bitcoin

+ Ethereum + Ripple(XRP)) represented less than 200 GB of storage -- resp. 150 + 32 (if state

history is pruned away) + 4 (#3 is already a lot smaller). 200 GB of storage is 40% of an

average hard disk or worse, is an average SD card for mobile-phones. The energy

consumption to keep this marginal ‘hard-disk’ operational in 2017 transcended the yearly

energy consumption in some countries in Eastern Europe...

Three thought experiments tell it all :

o Thought experiment #1: In 2014, the internet was estimated to be 10^24 bytes =

2000000000000000000 hard disks (https://www.livescience.com/54094-how-big-is-

the-internet.html). So even if I we could start ‘blockchaining’ and ‘uploading’ 60000

hard disks per day (= 1 hard-disk per second added to ‘the blockchain’) it would take

over 60 million year to finish that job. And then we only captured the internet

information in 2014. We are 2018 by now. So dream on that ‘one blockchain will rule

the world’…

o Thought experiment #2: 10-15 years from now we all will have dozens of blockchain

wallets: our identity records, our assets and (notary) contracts, our frequent flyer

miles and other fidelity cards, our voting rights, our energy/water/gas/ consumption,

our stock positions, our energy production using green technology, our passages over

toll-roads, our certificates / degrees / accomplishments / kudos / contracts, mortgages,

our jobs, our paid taxes & social security, our orders and deliveries, our reservations

and even our last will. So how will that all work? Will all ++7.6 billion of us have

dozens of blockchains to manage? Will we turn to trusted organizations and pay them

to run all these blockchains for us? Or will we just use urls URL’S (organizations /

https://www.livescience.com/54094-how-big-is-the-internet.html

https://www.livescience.com/54094-how-big-is-the-internet.html


3

8

Kurt Wayenberg

institutes that are here today and open up their portals) just as today, except that the

services offered by these portals/URL’s are cryptographically secured by then?

o Thought experiment #3: Suppose something goes wrong, terribly wrong, for hours,

for days, for weeks. To whom do you turn? For help? For complaints? For

compensation? How do you organize insurance in this context? A considerable

problem in a decentralized / distributed structure ‘everyone is responsible’ but

‘nobody is accountable’. This problem easily outshines other problems like

effectiveness and efficiency costs. It is the worst nightmare when things need to be

fixed.

Now, whatever the outcome and future of these overhyped products and technologies, the most

important point is that the game hás changed.

Today we demand from service providers and platform responsibles a lot more transparency, the usage

of mechanisms to cryptographically secure the data, the access by auditing authorities to check if the

data cannot be tampered with, etc…


3

9

Kurt Wayenberg

3.6 DXC.Portal Prototyping Platform

Our DXC Portal solution brings a full portal solution as your baseline for prototyping your [blockchain]

project requirements. It is only when designing Crypto-Ledger solutions that people start to realize the

impact on systems design. Let's study the difference between the classical and the new approach by

means of an example in the 'Energy market'.

Classical approach (aka Old way)

o Define the entities: Energy providers, energy production equipment, energy

consumers, group purchase, participation, production certificates, energy regulatory

authority,…

o Define the relations: energy consumers consuming energy from energy providers,

participants are energy consumers working together in a group purchase

o Define the transactions: register consumption, register production, distribute

certificates according to participation

o Build Db, build screens, prototype application, re-build, iterate

Crypto-ledger / Blockchain approach (aka New way)

o Define the parties: Energy providers, energy consumers, energy regulatory authority,

…

o Define the wallets: produced energy, consumed energy, participation, the sun

o Define the transfers of crypto currency energy: production equipment energy

(production every 15 minutes, daily division of certificates between participant)

o Upload in blockchain via excel tool, discuss and refine the concepts

The solution and approach is backed by a community of business experts. They bring to the table:

Business Expertise

Blockchain Expertise

Proprietary Model

Coaching Model

Train the Trainer

Development Individuals

In addition, base implementations and discussion models exist for a number of already 'prototyped' use

cases

Transfer of fluid assets

Consumption

Voting

Registration of public and private information

Text and documents

Track and trace

Asset management

Payments & Positions

Integrating multiple ledgers


4

0

Kurt Wayenberg

3.7 DXC.Portal Development Platform

Our DXC Portal Technology is a lot more than just blockchaintechnology: It is a platform for building

enterprise applications and has the following strong points:

Used, Stable, Efficient, Secure, Auditable

Rapid development and deployment

As stand-alone portal or integratable with legacy or COTS applications

Migration & Integration of existing ledgers

Zero license costs

DXC Open source

Development community

To learn more about the technical aspects, please consult the documentation on Architecture, Security

and Hosting, System Design And Development, Database Standard, Unit / Integration Testing, Best

Practices and Code Analysis.

To learn more about some horizontal business functionality, please consult the documentation on

Internet of Things, Decision Tables, Workflow, Reporting and GDPR.

The documentation can be accessed via the default menu (lower side information links)


4

1

Kurt Wayenberg

3.8 .Net DXC Crypto-ledger: Value Proposition

As a conclusion of this chapter we try to summarize the advantages of the .Net DXC Crypto-ledger:

Value Proposition in terms of 3 main benefits: It can help with assessing opportunities, it gives a major

jumpstart in application build, and it guarantees stability and performance regarding he application run.

The value proposition can be summarized as follows:

Opportunity Assessment

Identify, discuss and prototype blockchain opportunities with customers

Structured facilitation of audience

Identify quick wins, business case driven

Blockchain / Crypto consultancy

Application Build

Quickly deploy new solutions

Agile methodology

Rework existing solutions

Start small (POC), then expand

IP is with DXC

Leverage of existing code / assets

Application Run

24/7 proven, stable and performant

Compliant, secure, documented and auditable

Multiple hosting models

Multiple service models

When having questions regarding 'Opportunity Assessment' , please contact [email protected]

When having questions regarding 'Application Build' or 'Application Run', please contact

[email protected]




4

2

Kurt Wayenberg

Appendix A: Additional documentation on

http://trueandauthenticated.com

User Registration Process

Identity is one of the building blocks in our modern society. Without going into debate on all different

possibilities. Passports, electronic identities, bank cards, hardware tokens or [software] certificates or

without discussing about passwords, public and private keys, biometrics, n-factor authentication, etc...

So our solution also has a default basic user / identity management. It can be replaced by / integrated

with whatever solution you currently have implemented, yet for a matter of discussion or prototyping

the out of the box solution can be very useful. Especially when your solution needs to be open to user

groups currently NOT in your identity management system: suppliers, partner / customer companies,

(self-registering) end-users Á communities...

So find included a description of the out of the box user management process

1 User registers and gets a blockchain account

Account has been created

And user gets an account including a blockchain account and has status registered and can do a number

of things


4

3

Kurt Wayenberg

2 Upgrade the user account

So far one can work with the account anonymous. You can enter bogus data, a fake email address etc...

User can update that information as he gets more trust in the system, or if he wants to unlock more

functionality

It is only when your public information is filled in (last name, first name, street, zip, country) and when

the email is verified that your profile becomes public

User can issue an email verification (read: upgrading the account / going for full activation) by hitting

the upgrade account button

3 e-Mail Verify the account

A mail is send to the email account to verify the email

Status is now email verified

And the user can start filling up his ‘personal data’

4

4

Kurt Wayenberg

4 Advanced verification of the accounts

Based on the user data to be filled in, a registration in the blockchain can be initiated

There are 4 icons:

An action to get the string data as if it were to be put on the public blockchain: The string is:

o <Tx><LastName>Wayenberg</LastName><FirstName>Kurt</FirstName><Street>

Veldstraat</Street><HouseNumber>99</HouseNumber><Zip>2570</Zip><City>Du

ffel</City><BlockChainParty>99e7eac9707c499782fef562bf8e1502</BlockChainPa

rty><650526 421 37></650526></Tx>

The transaction to put publicly it on the blockchain

An action to get the string data as if it were to be put on the public chain: The string is:

VfgQycwzMKCA8I6S5rQQVaJ+4Es=

The transaction to put privately it on the blockchain


4

5

Kurt Wayenberg

Saving the tx gives an entry on the blockchain. The ‘public info’ is now validated and proven

5 Future extensions

Currently it is proven by logged on party and there is no logic yet as to the quality of the approvers or

to what the status of the user is following some approvals.

However, for starters… There is some status field that can be maintained…

4

6

Kurt Wayenberg

Appendix B - Asymmetric Key Pairs

John Doe Private key

<RSAKeyValue><Modulus>p7J7PVqyPEpiGKL++i8ptVMQD5oBiV0e06T7NW3uaTy3CaufluPnzAl8AlpKB0rV+LU/oA

Z7qQAcbRTLJJbjcXYa3ciaasWv44DU53QIb/aHnkmB8RPFbizCrlUIR0f0iGijYDz/2DSRkeBVJXbF1+l0VBKTlgt2uLbh8

riAB38=</Modulus><Exponent>AQAB</Exponent>6Lyvf+F5/0BtDYOtQwxscwL9bSfyS5zM7zT5icKsJM6lHHj1tzA

PuS14OtHmcOoihwLSXvCG7MH+dvsmwBDUkw==<Q>uHWLi3P9APzWhYQkghiVcao1O11ZPYKFMMccFRySQ

3bhXfv+85PcRqw5M21njdWKO71YeNpKJ+GKzE92bNKg5Q==</Q><DP>vGoEqkKfwUUnBAnV+rHUGkgRYo00WoJ

WZlE8s4omUqX4hVRnmCYQlJl6/CNxq3fg++wM409V69Yha7FnbZYygQ==</DP><DQ>oZz7YneBWHguTFT217VKW

ohSk2y6X5YXtCD/jc+2pr1lv76mJiuKd7E1fMWCUVajAqxm85vuFPsbbN7CV55DsQ==</DQ><InverseQ>MQf+4ISm4h

8JbR3xCVfJ39Suv2eFe8MaFIg0u25NLhocRqJcxbFx1wCCtlK6aXtpfBPMD24viVOnii8Dh0Hy8g==</InverseQ><D>HoO

OgzJ+nhPW167JAJMWXsUXdg9K2kjUdCRgBW/UYtfGYn8VEeq0Yd8T7oWpVLxcRN4ODrs/QxgfFAYllKnUBqRSFF

KmOkkiO1GU8K4a+gtLmCv57NFWumHkvSLgQpoZCRvi3HYGa0uIbdG0gbl4Pd/UBnCI2bYj5U1+KvW1bqk=</D></R

SAKeyValue>

John Doe Public Key

<RSAKeyValue><Modulus>p7J7PVqyPEpiGKL++i8ptVMQD5oBiV0e06T7NW3uaTy3CaufluPnzAl8AlpKB0rV+LU/oA

Z7qQAcbRTLJJbjcXYa3ciaasWv44DU53QIb/aHnkmB8RPFbizCrlUIR0f0iGijYDz/2DSRkeBVJXbF1+l0VBKTlgt2uLbh8riAB38=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>

System public key

<RSAKeyValue><Modulus>xssq6jvpJTUvwBGnYNnAEenShaBZqBwArxjScI/+jYUoXousTAzs2lNnbR0yxvnNl08qWttE

92WCk+qVlNWRHGD1eB8AtzbEK28lVCWuT32bT6QOwhuxMITubntlC7BU/ODU6tcigAqDimZ2hj6FajIYgiZl3WGSywqmJ8eEml8=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>

Jack Doe Public Key

<RSAKeyValue><Modulus>kDPN9LYmUATkYKASDyebF7OQ5K7+goJ1q2xRAtO1/eFM+UJ1WmQzII9FriU5SFfJ4p5

X8rqoEDFtUCpVeM/bu3xwJRtJcGJiYoVSAo7h14ShTZUSOw2b0OTAJJLGwVTKApMihuxGnsdgVpeb6/043iwgX6SLV

FlcH7d5LyATCfE=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>

Jack Doe Private Key

<RSAKeyValue><Modulus>kDPN9LYmUATkYKASDyebF7OQ5K7+goJ1q2xRAtO1/eFM+UJ1WmQzII9FriU5SFfJ4p5

X8rqoEDFtUCpVeM/bu3xwJRtJcGJiYoVSAo7h14ShTZUSOw2b0OTAJJLGwVTKApMihuxGnsdgVpeb6/043iwgX6SLV

FlcH7d5LyATCfE=</Modulus><Exponent>AQAB</Exponent>xy25dt9/Nd+ZJIzkRQ3jlbTJANSY35ZVEfToDBTnr5

BXuEcWG2k5FoRFr6DJ9FNcP4pLFsDwxRvtEuuRQX2a3Q==<Q>uVcXos54SmNjog/kTOacPsxP++5+v59iBM5M

mEl9A3kPgAlswdX+JQDusluUe24qvRVedrJMst4aLp38QzvIJQ==</Q><DP>w+JXJO52yD/n98dMdBFNwpyylct/sVzCu0

81qzQgC0yUyJm4xyp7x4Y8lpY2J8CX17GlWXJVGDT3ugTMrTDfTQ==</DP><DQ>ZL1oBYBAdf6L2zzUFNCMQL4

BA6jgj/tr5bzUeToIj2iv+iIlUT6lgyt8ksmgbW62IEyLKe1ELzz18jzBLzJBWQ==</DQ><InverseQ>iaFIWyfHDfNGJqQbjw

VaxR5SivewPWeJMlIOtN5evQkJ8DXerzsc6ku6Bja2cXvUZr0viCVrRJN29WzezrIMlA==</InverseQ><D>HIFRFi2nlyvQ

ZVVfHIXMv7usSbhZ8TyOvCs2PGPTVvNhfuhnQE4MWURZFtqe3zETZGu+oOnK7SCIJk+oA7C7E6G73ChRLm0snbU8J9FarXnQc/Ujt7JMFo/Ejz1GfgEvjMZAO7Mo2Iwp7jJBbv7m92IZhGU+Ss+Uz5cInp6R81E=</D></RSAKeyValue>

4

7

Kurt Wayenberg

Troy Private Key

<RSAKeyValue><Modulus>xqJvoMECg2Kj+M9SkjDeUK58sKJpvE1F2Nz2HyKNroCYJWo3Q1CHDkUneRa8oYvJcHo

hWhDotLQV8qFS3hNUDSGdJfLVV7RdG0LJ0Rrh423hJWQW5k3bbKvBtaTqT14ReBNXiOZ+AVNs3nCaXAGUX5SA

UdTjoti4sSxz3wUHYL0=</Modulus><Exponent>AQAB</Exponent>+G4ZilQwSCq1I0Z7aq8SIGNDnQbvRvfTYZ9L

H2ALVJsU42klscgCKflys3CpQ8f8Cc+7Rp4pX2HPmD6s5FAN/Q==<Q>zK/m1n0TrhsMQGImIp1LoOEelqOuTkUJ

mEuSQji1EvrqCBXP+ztfr3tmt6pqal2w5JcVwK1DRSa3lEgXqSW5wQ==</Q><DP>z80wme+v7z2iBJ65L1S/wc2mSdv6H

A/Chb771IO/FoceItbaC+p0PO4GDqinPSYz4XUcfoZfrwQe5IdQkS2RdQ==</DP><DQ>o+XR5DvBD2+PDtrIiH0FOuwn7

x1fjELRnQYeNjJsI6eQ0CqPIC95ve0E4dpuXX9qDpBAFclnDS8kXnKfp4ySwQ==</DQ><InverseQ>tgIFxaevdFpxkTzUE

/G1X+MHPL+20YRLUV3oHOSvr4cGaQK2nZiQ5oCbt7IhzTdxqNp2hNNfFON22JPfOiwmfQ==</InverseQ><D>HinMib

zFhO4VuFLDVy/Ukqvsg2YmaFHTqXrkZRX6LeWZNRVMDwzLdX9K3zh0rJNto4boSaUHsWknbBDTZKXKvW7uX+Y

seFMFeMBJac82RXZQ19Minmhqq6d12KFgYTVMyrkiSjkQRedfomOTUIha5wYSGV0fIBwMtFQIzVwa4AE=</D></RS

AKeyValue>


4

8

Kurt Wayenberg

6 Appendix C - Lorum Ipsum Text Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a,

venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium. Integer tincidunt. Cras dapibus. Vivamus elementum semper nisi. Aenean vulputate eleifend tellus. Aenean leo ligula, porttitor eu,

consequat vitae, eleifend ac, enim. Aliquam lorem ante, dapibus in, viverra quis, feugiat a, tellus. Phasellus viverra nulla ut metus varius laoreet. Quisque rutrum. Aenean imperdiet. Etiam ultricies nisi

vel augue. Curabitur ullamcorper ultricies nisi. Nam eget dui.

Etiam rhoncus. Maecenas tempus, tellus eget condimentum rhoncus, sem quam semper libero, sit amet adipiscing sem neque sed ipsum. Nam quam nunc, blandit vel, luctus pulvinar, hendrerit id, lorem. Maecenas

nec odio et ante tincidunt tempus. Donec vitae sapien ut libero venenatis faucibus. Nullam quis ante. Etiam sit amet orci eget eros faucibus tincidunt. Duis leo. Sed fringilla mauris sit amet nibh. Donec

sodales sagittis magna. Sed consequat, leo eget bibendum sodales, augue velit cursus nunc, quis gravida magna mi a libero. Fusce vulputate eleifend sapien. Vestibulum purus quam, scelerisque ut, mollis

sed, nonummy id, metus. Nullam accumsan lorem in dui. Cras ultricies mi eu turpis hendrerit fringilla. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; In ac dui quis

mi consectetuer lacinia.

Nam pretium turpis et arcu. Duis arcu tortor, suscipit eget, imperdiet nec, imperdiet iaculis, ipsum. Sed aliquam ultrices mauris. Integer ante arcu, accumsan a, consectetuer eget, posuere ut, mauris.

Praesent adipiscing. Phasellus ullamcorper ipsum rutrum nunc. Nunc nonummy metus. Vestibulum volutpat pretium libero. Cras id dui. Aenean ut eros et nisl sagittis vestibulum. Nullam nulla eros, ultricies

sit amet, nonummy id, imperdiet feugiat, pede. Sed lectus. Donec mollis hendrerit risus. Phasellus nec sem in justo pellentesque facilisis. Etiam imperdiet imperdiet orci. Nunc nec neque. Phasellus leo dolor, tempus non, auctor et, hendrerit quis, nisi.

Curabitur ligula sapien, tincidunt non, euismod vitae, posuere imperdiet, leo. Maecenas malesuada. Praesent congue erat at massa. Sed cursus turpis vitae tortor. Donec posuere vulputate arcu. Phasellus

accumsan cursus velit. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Sed aliquam, nisi quis porttitor congue, elit erat euismod orci, ac placerat dolor lectus quis

orci. Phasellus consectetuer vestibulum elit. Aenean tellus metus, bibendum sed, posuere ac, mattis non, nunc. Vestibulum fringilla pede sit amet augue. In turpis. Pellentesque posuere. Praesent turpis.

Aenean posuere, tortor sed cursus feugiat, nunc augue blandit nunc, eu sollicitudin urna dolor sagittis lacus. Donec elit libero, sodales nec, volutpat a, suscipit non, turpis. Nullam sagittis. Suspendisse

pulvinar, augue ac venenatis condimentum, sem libero volutpat nibh, nec pellentesque velit pede quis nunc. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Fusce id

purus. Ut varius tincidunt libero. Phasellus dolor. Maecenas vestibulum mollis diam. Pellentesque ut neque. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.

In dui magna, posuere eget, vestibulum et, tempor auctor, justo. In ac felis quis tortor malesuada pretium. Pellentesque auctor neque nec urna. Proin sapien ipsum, porta a, auctor quis, euismod ut, mi.

Aenean viverra rhoncus pede. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Ut non enim eleifend felis pretium feugiat. Vivamus quis mi. Phasellus a est.

Phasellus magna.

In hac habitasse platea dictumst. Curabitur at lacus ac velit ornare lobortis. Curabitur a felis in nunc fringilla tristique. Morbi mattis ullamcorper velit. Phasellus gravida semper nisi. Nullam vel sem. Pellentesque libero tortor, tincidunt et, tincidunt eget, semper nec, quam. Sed hendrerit. Morbi ac felis. Nunc egestas, augue at pellentesque laoreet, felis eros vehicula leo, at malesuada velit leo quis

pede. Donec interdum, metus et hendrerit aliquet, dolor diam sagittis ligula, eget egestas libero turpis vel mi. Nunc nulla. Fusce risus nisl, viverra et, tempor et, pretium in, sapien. Donec venenatis

vulputate lorem.

Morbi nec metus. Phasellus blandit leo ut odio. Maecenas ullamcorper, dui et placerat feugiat, eros pede varius nisi, condimentum viverra felis nunc et lorem. Sed magna purus, fermentum eu, tincidunt eu,

varius ut, felis. In auctor lobortis lacus. Quisque libero metus, condimentum nec, tempor a, commodo mollis, magna. Vestibulum ullamcorper mauris at ligula. Fusce fermentum. Nullam cursus lacinia erat.

Praesent blandit laoreet nibh.

Fusce convallis metus id felis luctus adipiscing. Pellentesque egestas, neque sit amet convallis pulvinar, justo nulla eleifend augue, ac auctor orci leo non est. Quisque id mi. Ut tincidunt tincidunt

erat. Etiam feugiat lorem non metus. Vestibulum dapibus nunc ac augue. Curabitur vestibulum aliquam leo. Praesent egestas neque eu enim. In hac habitasse platea dictumst. Fusce a quam. Etiam ut purus

mattis mauris sodales aliquam. Curabitur nisi. Quisque malesuada placerat nisl. Nam ipsum risus, rutrum vitae, vestibulum eu, molestie vel, lacus.

Sed augue ipsum, egestas nec, vestibulum et, malesuada adipiscing, dui. Vestibulum facilisis, purus nec pulvinar iaculis, ligula mi congue nunc, vitae euismod ligula urna in dolor. Mauris sollicitudin

fermentum libero. Praesent nonummy mi in odio. Nunc interdum lacus sit amet orci. Vestibulum rutrum, mi nec elementum vehicula, eros quam gravida nisl, id fringilla neque ante vel mi. Morbi mollis tellus

ac sapien. Phasellus volutpat, metus eget egestas mollis, lacus lacus blandit dui, id egestas quam mauris ut lacus. Fusce vel dui. Sed in libero ut nibh placerat accumsan. Proin faucibus arcu quis ante. In consectetuer turpis ut velit. Nulla sit amet est. Praesent metus tellus, elementum eu, semper a, adipiscing nec, purus. Cras risus ipsum, faucibus ut, ullamcorper id, varius ac, leo. Suspendisse feugiat.

Suspendisse enim turpis, dictum sed, iaculis a, condimentum nec, nisi. Praesent nec nisl a purus blandit viverra. Praesent ac massa at ligula laoreet iaculis. Nulla neque dolor, sagittis eget, iaculis

quis, molestie non, velit.

Mauris turpis nunc, blandit et, volutpat molestie, porta ut, ligula. Fusce pharetra convallis urna. Quisque ut nisi. Donec mi odio, faucibus at, scelerisque quis, convallis in, nisi. Suspendisse non nisl

sit amet velit hendrerit rutrum. Ut leo. Ut a nisl id ante tempus hendrerit. Proin pretium, leo ac pellentesque mollis, felis nunc ultrices eros, sed gravida augue augue mollis justo. Suspendisse eu

ligula. Nulla facilisi. Donec id justo. Praesent porttitor, nulla vitae posuere iaculis, arcu nisl dignissim dolor, a pretium mi sem ut ipsum. Curabitur suscipit suscipit tellus.

Praesent vestibulum dapibus nibh. Etiam iaculis nunc ac metus. Ut id nisl quis enim dignissim sagittis. Etiam sollicitudin, ipsum eu pulvinar rutrum, tellus ipsum laoreet sapien, quis venenatis ante odio

sit amet eros. Proin magna. Duis vel nibh at velit scelerisque suscipit. Curabitur turpis. Vestibulum suscipit nulla quis orci. Fusce ac felis sit amet ligula pharetra condimentum. Maecenas egestas arcu

quis ligula mattis placerat. Duis lobortis massa imperdiet quam. Suspendisse potenti.

Pellentesque commodo eros a enim. Vestibulum turpis sem, aliquet eget, lobortis pellentesque, rutrum eu, nisl. Sed libero. Aliquam erat volutpat. Etiam vitae tortor. Morbi vestibulum volutpat enim. Aliquam

eu nunc. Nunc sed turpis. Sed mollis, eros et ultrices tempus, mauris ipsum aliquam libero, non adipiscing dolor urna a orci. Nulla porta dolor. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos.

Pellentesque dapibus hendrerit tortor. Praesent egestas tristique nibh. Sed a libero. Cras varius. Donec vitae orci sed dolor rutrum auctor. Fusce egestas elit eget lorem. Suspendisse nisl elit, rhoncus

eget, elementum ac, condimentum eget, diam. Nam at tortor in tellus interdum sagittis. Aliquam lobortis. Donec orci lectus, aliquam ut, faucibus non, euismod id, nulla. Curabitur blandit mollis lacus. Nam

adipiscing. Vestibulum eu odio.

Vivamus laoreet. Nullam tincidunt adipiscing enim. Phasellus tempus. Proin viverra, ligula sit amet ultrices semper, ligula arcu tristique sapien, a accumsan nisi mauris ac eros. Fusce neque. Suspendisse

faucibus, nunc et pellentesque egestas, lacus ante convallis tellus, vitae iaculis lacus elit id tortor. Vivamus aliquet elit ac nisl. Fusce fermentum odio nec arcu. Vivamus euismod mauris. In ut quam

vitae odio lacinia tincidunt. Praesent ut ligula non mi varius sagittis. Cras sagittis. Praesent ac sem eget est egestas volutpat. Vivamus consectetuer hendrerit lacus. Cras non dolor. Vivamus in erat ut

urna cursus vestibulum. Fusce commodo aliquam arcu. Nam commodo suscipit quam. Quisque id odio. Praesent venenatis metus at tortor pulvinar varius.


4

9

Kurt Wayenberg

Appendix D - Other Blockchain Solutions

The above discussion focused primarily on the top 2 blockchains: Bitcoin & Ethereum. There are

however other blockchain solutions, probably over 100... Some of these solutions claim they got rid of

the problems with performance, efficiency and energy-greed, issues central to BitCoin & Ethereum.

Some systems just focus on setting-up a private blockchain e.g. between 5 nodes and even 'skip' the

consensus algorithm. That obviously solves a lot of problems but that solution comes creepily close to

the solution discussed in this paper. Except that it uses a software solution of which 85% of the

functionality is not used.

There solutions by no time also require a distributed database to store the data not in the blockchain but

shared by everyone.

The final challenge than is that every 'node' needs a 'front-end / back-end solution' that uses the

blockchain but hides all the integration complexity. A lot of solutions come these days all installing the

same application / application API and e.g. an Ethereum EVM. The question you should pose is whether

this solution still is the distributed solution you look for or whether it is a lousy and inefficient

implementation of a portal...

Some solutions also claim they do something fundamentally different: We take a look at a few of them...

IOTA

IOTA claims to be an alternative to blockchain. They have set up a tangle. They also dumped the 'block'

in blockchain and went to 'transaction by transaction' chaining.

Allthough they claim that one day they will be fully decentralized but as long as they remains small

(they don’t really define what that means) they still have a strong centralization component or even

central copies of the transactions)

TheIr prerequisite is that everyone that submits a transaction has to validate two more transaction. This,

at first looks interesting as a nice solution against DDOS but will give problems when confronted with

non-professional behavior at the edges of the tangle. As expected there indeed is a problem with a lot

of unconfirmed transactions there… see this link

Even worse, it suffers from hackers behavior and misuse… I did found some horror posts a.o. see link

(https://github.com/iotaledger/wallet/issues/734)

Another very strange design is their address key generation: IOTA address generation

This is a nightmare to get build in in real business systems. In addition it is really insecure and as a

result has led to the rule that after every receipt you should generate a new address. See link:

https://www.reddit.com/r/Iota/comments/6hm9uc/what_is_the_point_of_generating_new_address_to/

The security is not dramatic as far as I know – although also other people have some concerns (see link:

https://www.reddit.com/r/Iota/comments/6gzkd2/iota_sounds_great_but_hows_the_security/divsnh7/)

One specific concern has to do with tip selection algorithm and what the designer himself calls the

parasite chain attack (see https://iota.org/IOTA_Whitepaper.pdf p. 20) - see also

https://iota.stackexchange.com/questions/tagged/tip-selection

https://iotasear.ch/address/XIXDSLBBLNLRJEPHOSRDHGV9FYZBUQUCHJFNKKFUVFBYMWTLYVCAXOXDSBYPYDUKPUXCOTYCL9IQJWWZWUKFJGFYQD

https://github.com/iotaledger/wallet/issues/734

https://learn.iota.org/tutorial/generating-addresses-learn-the-basics

https://www.reddit.com/r/Iota/comments/6hm9uc/what_is_the_point_of_generating_new_address_to/

https://www.reddit.com/r/Iota/comments/6gzkd2/iota_sounds_great_but_hows_the_security/divsnh7/


5

0

Kurt Wayenberg

IBM Blockchain

I am still not sure about this one. Not at all. For sure it has a very strong central component (which I

obviously consider it a good solution) and as such it has a very performant solution. Nevertheless the

distribution context is still very dominantly present. I am not sure what the added value is as their nodes

resemble replication, more than distribution

Corda

The unique difference with CORDA is that they limit the consensus algorithm to involve only the parties

that are impacted by the transaction.

The platform seems to be successful. It is closer to a central solution as discussed in this paper including

the integration part with other parts (blockchains). Besides focusing on characteristics like validity,

uniqueness, immutability and authentication, they still have a component of 'consensus' in them.

I do think this is a nice extra although for me it is not clear if it is part of the transaction or more as an

action taking place in the aftermath of a transaction. By all means, Corda itself claims that it is not a

blockchain (see link). And neither is it a word that you will find in the popular Azure marketplace

infomercial (see link here)

JD.com

Chinese ecommerce giant JD.com announced that they are partnering with the Australian beef exporter

InterAgri to launch a blockchain-enabled traceability system aimed at providing greater transparency

about the provenance of beef sold in China.

The blockchain system will only be implemented later 2018, but it is astonishing to see how very basic

the scope will be:

it will enable consumers to track each piece of 'Pure Black Angus' beef back to the farm in

Australia where it originated

For that a cooperation between 4 parties is set-up: Walmart, JD.com, IBM, and Tsinghua University

National Engineering Laboratory for E-Commerce Technologies

The four companies will work together to create a standards-based method of collecting data about the

origin, safety and authenticity of food, using blockchain technology to provide real-time traceability

throughout the supply chain. This will encourage accountability and give suppliers, regulators and

consumers greater insight and transparency into how food is handled, from the farm to consumers. This

has traditionally been challenging due to complex and fragmented data sharing systems that are often

paper-based and can be error-prone.

An interesting discussion... it is clear that this team is still in its infant state about food chain traceablitiy.

The organization puts forward a blockchain without any details on how they will realize it. They still

have a long way to go if I compare it with the Federal Food Agency in Belgium whho has done this

exercise already and has a full platform in place. Anyhow, I doubt that they will have a 'blockchain'

solution a few months from now.

https://www.ccn.com/r3-corda-is-not-a-blockchain-and-we-didnt-say-it-was-as-critics-take-aim/

https://azure.microsoft.com/en-us/blog/r3-on-azure-strengthening-our-partnership/


5

1

Kurt Wayenberg

Important however, safety for the food chain is a very important concern for the community, so it is no

wonder that things are in motion and that people look at 'blockchain' technology to add transapacrancy,

proof & dispute resolution to their solution.

Today DXC is studying with the Belgian Federal Food Agency how cryptographically signed ledgers

can further improve the confidence to even the most cynical persons


5

2

Kurt Wayenberg

Appendix E: Integrating Legacy Information Systems

In this appendix we give three examples on how certain data can be made immutable: Documents,

images and data-tables.

1 Making documents immutable

Consider a document system which allows to manage (HTML) documents. It maintains versions,

manages text frgment copying, numbering schemes and sorting, security, etc...

Now as a version gets published, it cannot be changed anymore. But how sure are we?

By putting the 'hash' of the document in the blockchain the docoment becomes immutable.

In order to initiate this action, hit the icon 'Publish in BlockChain' in the top right tool bar. (The image

underneath shows the action as done on a previous version of this document)

Hitting the button extracts the full document as html and creates a hash. That hash is then put in the

blockchain. Study the 'content' record that is being created. It specifies that the 'resource':

with url: http://trueandauthenticated.com/Portal/en/Document/Browse/11198

of type: 'Html'

Has Base64Sha1: yYqJcw/OBn/mQcnGE1pz2YAJ92EGnTUik5qmA8MNn/M=

The submission in the blockchain database is confirmed via mail, together with the 'proof' that it has

been submitted.


5

3

Kurt Wayenberg

The document is now made immutable.

Suppose there is a flaw in the system allowing you to change a character somewhere, or suppose there

is a hacker that has corrupted a part of the text. With every 'check' by the resource the 'completely

different hash' will signal that the resource has been changed!

Only the unchanged document will generate the correct hash.


5

4

Kurt Wayenberg

10.2 Making images immutable

What about images? A similar story.

The overview shows the images. How can you assure the image has not been tampered with? You

publish its hash in the blockchain!

In order to initiate this action, hit the icon 'Publish in BlockChain' in the top right tool bar.

Hitting the button reads the image and converts its contents to a base64 string and creates a hash. That

hash is then put in the blockchain.

Study the 'content' record that is being created. It specifies the 'resource' URL, the type (IMG) and the

hash. This information allows the blockchain transaction to check if the image still returns the expected

hash.

From now on the image is immutable. Changing eve a pixel generates a completely new hash and so

any change is detected.


5

5

Kurt Wayenberg

10.3 Making data tables immutable

For making the contents of legacy tables immutable, one has to define a good process and a number of

criteria that help you define when and how to make a certain part of a table unique.

In the example underneath we make the table which measures the customer's SLAs immutable. What

the batch process does is iterate through all days for which no immutability record does not exist yet.

For that specific day all records (based as a combination of ordered records and some selection of

critical fields) are taken and a 'hash' is constructed.

The blockchain database lists the hash for each day. The hash is put into the blockchain and the

table now has become cryptographically secured against tampering.

Blockchain Discussion Paper -...

Documents

Transcript of Blockchain Discussion Paper -...