[Cryptography] Blockchain to Secure Nuclear Weapons?

[Peter Todd]

On Thu, Oct 13, 2016 at 03:23:15PM +0100, Ben Laurie wrote:
> On 13 October 2016 at 15:14, Natanael <natanael.l at gmail.com> wrote:
> > The gap is the ability vs lack of ability to say that there's no data being
> > hidden from you, the ability to know when you have access to one entry that
> > there is no entries that conflict with yours.
> >
> > A pure timestamping service has no concept of conflicts or versioning.
> > There's no concept of exclusivity or "rivalry". But in Bitcoin's blockchain
> > you can't spend an UTXO twice,
> 
> Which requires clients to have a complete copy of the blockchain,
> right? Its not efficient, though. That's why we're doing Trillian
> (https://github.com/google/trillian).

That's not quite correct: you can verify UTXO based auditable logs with
just the UTXO set, not the complete blockchain. Either by downloading, then
discarding, the complete blockchain with a pruned full node, or with
lite-client security by assuming that miners are validating transactins
correctly in the most-work chain.

Specifically, the way you achive this is to use transaction outputs as
anti-replay devices. Each state in your log is associated with a unique txout,
and a new state is only considered valid if the previous state's txout was
spent in a transaction committing to the new state (and a new txout for that
new state). Since duplicate spends are prohibited in Bitcoin, a proof for such
a long only needs to show merkle paths to each transaction - a log2(n) proof
due to Bitcoin's merkle tree.

A subtelty of this approach is that to prove that a new version of a given log
_doesn't_ exist currently requires the full contents of all blocks past the
last transaction; (U)TXO commitments(1) will improve on this.

As applied to Trillian, you could have a Trillian log whose uniqueness is
proven by the fact that there is a unique set of txouts that have been spent
for the version of the log that you are looking at. Equally, you can stack this
concept, with a meta log of uniqueness proofs (and signatures) for sub-logs, at
the cost of being vulnerable to the trusted third party in control of the
txouts: they can prevent you from being able to update your sub-log.

1) https://petertodd.org/2016/delayed-txo-commitments

> > in Certificate Transparency you can't issue
> > two separate certificates for one domain undetected (revocations are also
> > tracked).
> >
> > Factom (works on top of Bitcoin) goes even further, when you look up entries
> > you should be able to confirm that what you hold is the latest version, or
> > to otherwise find the one correct latest version. It ensures there's only
> > one active version at a time, no forking. Each new one replaces the previous
> > one. They call it proof of process.
> 
> Sounds like Trillian.

It is like Trillian, though with a fairly complex architecture due to the
"Factoid" appcoin... I'm skeptical that Factom is a competitive architecture:

https://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/cph0pvo?context=3

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161013/e1d44308/attachment.sig>