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”


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