Quote from: cryptovore on August 07, 2017, 11:20:33 AM

Ricardian contracts (or any smart contracts) can be parseable in RDF, but they must be enforced first at the blockchain level.

You're probably right, I was basing my understanding of a quick skim of:

Ian Griggs' Introduction to Ricardian Contracts, retrospective (begins at p45 of the Smart Contract Templates PDF). Note: Smart Contract Templates

Quote

Lightbulb - The Contract IS the Issue
Flip the logic upside down
keep prose document as is
let the program extract its parts from document
place the users -issuer+holder- first
and the developer second

As developer, I dont need to convert the bond
1. capture into signed digital document
2. read out 10 or so values
3. identify the document for accounting

...

The Hash as identifier
PGP again provided the clue
cryptographic message digest or Hash
Turns any document into number:
1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3
(Hal Finneys Bitcoin account)
Hashes are:
Secure, unique, global, free
1:1 with your document
...

The Ricardian Contract
Captures any legal prose contract
any financial deal
no harder to read or write than any other contract
(too) brutally honest
not good for hiding intent
Signed and Hashed
self-identifying, self-verifying
hash makes participation in any digital agreement trivial
add keys & server locs for self-assertion, self-routing
Easy to implement 1000 lines of code

In my book, that's a match. It may not match anyone else's notion of a Ricardian contract but I've got all that I need from it. For his kind of Ricardian contract to be considered complete by the parties prepared to commit to abiding by it, you need i) a formal description of the domain ii) a script to execute the described instructions and iii) a metadata representation scheme capable of making statements in the domain about outcomes of the script.

From my reading of the runes, it's not that the whole process is automated, only the (mutually-agreed) blockchain part of it is. It's that the accompanying formal annotation is usefully more precise than NL for certain common tasks and so can be abstracted to the design level, devolving the tedious implementation details to semantic and syntactic engines.

That's the theory anyway. Success will depend on whether the DSL (Domain-Specific Language) and the TSL (Transaction Scripting Language) were designed with enough sensitivity to the inevitable power / expressibility / comprehensibility tradeoffs. Somewhere in the annals of bct, gmaxwell avers that the Bitcoin scripting engine is quite capable of expressing smart contracts and hints that we might want to reflect on whether the power of a Turing-complete language is actually desirable in this instance (it isn't, imo). Having blundered around these byways for some time, I know where Griggs' efforts are going to get bogged down. I can see two pain points in Griggs' slides. The first is the formalisation of the domain of contracts - aka knowledge acquisition and representation. This is still very much an ill-understood, specialist subject and without recognising that, they are not likely to be able to make much actual progress. The second pain point is going to be the characteristics of the TSL in computational linguistic terms.

I share Griggs' enthusiasm for re-purposing cryptographic hashes as identifiers --- by prefixing a few characters to a blockhash I have an RDF identifier with increased confidence in its uniqueness. It's a direct mapping, works for tx hashes too, and addresses. We should specialise the ccy vocab to Slimcoin and use a dedicated namespace:

PREFIX slm:

slm:C00000d7e8a80fec4057cb6d560822705596040bf41f0ebb2465dcdf46e4c517e

I believe RDF gives us some slight operational edge in that what is notarised is a fully formal description of the object that is capable of carrying a significant information payload, including arbitrary serialisations of the object, (video, audio, image, text) etc. and the metadata allows indexing and cataloguing.

OP_RETURN capacity is configurable - https://github.com/slimcoin-project/Slimcoin/blob/master/src/script.h#L27

static const unsigned int MAX_OP_RETURN_RELAY = 80; // bytes

ViaCoin has a generous 128 bytes, IIRC. I've configured Slimcoin's a little more economically. 100 seemed a bit lavish, after putting a few URLs into it. But the value could be bumped up a bit or even a lot (what other plans for the coin are there?). Slimcoin's 90s rapid-fire block emission rate offers a relatively low impedance to inscription txs. They get quickly cleared away rather than piling up.

Keybase.io is another outfit writing its stuff to the bitcoin blockchain, it uses the popular merkle tree approach of locking hash references using OP_RETURN.

Oh, Project Provenance is also interesting.

Cheers

Graham