Noark and blockchain ... a bit of info ...

[Petter Reinholdtsen]

[Thomas Sødring]
> Just to follow up on a discussion, here is some information about the
> work I'm trying to do to integrate Noark 5 with block chain.

Thank you.

> So to deliver on the "bestilling" I need to find a distributed
> blockchain implementation, that will allow me write, at a minimum,
> systemId and a timestamp for CUD events.

I am quite sure bitcoin allow that.

But instead of trying to track down a public ledger you can write to,
what about simply simulate it using trusted timestamps and a internal
changelog.

Make a database table consisting of a sequence counter
(timestamp/counter/whatever) and the fields you want to track.  In
addition you need a checksum and away to store a trusted timestamp
value:

 * timestamp
 * systemid
 * checksum
 * tts-value

Every time something change, you create the checksum of the timestamp,
the systemid and the previous checksum, and ask for trusted timestamp
value of this checksum.

You can read more about how to get a trusted timestamp in
<URL: http://people.skolelinux.org/pere/blog/syslog_trusted_timestamp___chain_of_trusted_timestamps_for_your_syslog.html >.

In short, it is simply to do something like this:

  echo '$timestamp $systemid $oldchecksum" > /tmp/file
  openssl ts -query -data "/tmp/file" -cert -sha256 -no_nonce \
    | curl -s -H "Content-Type: application/timestamp-query" \
           --data-binary "@-" http://zeitstempel.dfn.de > /tmp/file.tsr

You can then store the content ot file.tsr in the database.

This would create a chain of signed checksums.  The signature can be
used to both detect holes in the sequence and prove that a given
checksum existed at a specific point in time.  This approach will both
make the archive tamper evident (any missing events/changelog entries
can be detected) and prove that a given file has not been changed after
it was stored.  It will not make anything available to the public, of
course, but see below if that is a goal.  The changelog could be made
public to allow anyone to verify its content, but without the archive
content it would not be possible to verify that files have not been
modified.

This will simulate a several parts of a public block chain.  The p2p
broadcasting is taken out (stored locally instead) and the "proof of
work" part is replaced by a trusted third party.

> In many ways using blockchain is about exposing what is happening
> inside government, without exposing any private details. It makes the
> archive more "public" in that its internals are exposed in a trusted
> verifiable manner.

I fail to see how publishing the systemid is going to expose anything
about what is happening inside a government.  To get that effect more
information need to be made public.

Perhaps record type, case number, operation type etc need to be exposed
to have that effect?

What exactly should be available to the public, and what should not?

-- 
Happy hacking
Petter Reinholdtsen