Thanks for taking the the time to respond, always appreciating your posts.
Generous of you to say so. I'll grab any excuse for an opportunity to
pontificate paint some more pictures.
I see a subtle, yet, in my opinion, very important issue when the storage of the contract is referenced in another realm which is not enforceable by the same rules, or by the same source as the proof of the contract (the hash of the transaction).
I disagree that the difference is subtle. I see it as complete, unbridgeable and profound. As isolated cognitive entities, we are also ungrounded. I like Marmite, let's say, for the purposes of discussion, you don't. What does it
mean to you when you say “Graham likes Marmite”. Where's the semantic grounding located? How do you “prove” that statement in a way that is both sound in an epistemological sense and would also satisfy your local LISP programmer as a specification that could be coded to work reliably and accurately? We can't. But it doesn't slow us down.
As autonomous cognitive entities, we are
functionally adequate. If we make a fatal mistake, someone else will arrive at another solution - rinse and repeat, general progress of the many continues at the occasional cost of a venturesome individual. Too bad about the fallen poppy but hey, we got
fields of 'em. Next volunteer, please.
We (not me, I hasten to add) dreadfully abuse our artificially-created non-autonomous cognitive entities by wanting them to be
formally adequate, provably “correct”, no product must ever be allowed to make a single mistake. That would be a huge failure and undermine people's faith that the technology always produces unbiased,
correct answers - such as “Graham likes Marmite”. Unfortunately, the formalism is inadequate for its purpose and probably always will be (c.f. Joseph Becker). For a kick-off, it ignores the possibility that Graham might just be lying about his uninspectable mental state, gambling on the near-certainty that no-one can prove otherwise.
But, apart from IPFS, the latter two are not enforceable
Someone on HN posted a summary, I clipped it for my NOTES3.md file (in which I keep a copy of stuff that's informing my thinking, Ngaio's working her way through NOTES1.md):
[HM: libertymcateer](
https://news.ycombinator.com/item?id=14945061)
I have been saying this for quite sometime on this forum - contracts have to deal with ambiguous circumstances and expressly contemplate being resolved in courts. Ambiguity of contracts is a *feature*, not a bug, as it is in the interest of both parties to be able to argue about certain unanticipated events when they occur.
Quoting my own comments from a while back:
> The vast majority of contracts do not have syntactically testable conditions. They just don't. Whether the conditions in a contract have been met is very often a matter of huge debate - this is what "law suits" are about. Unless you can create a condition that is testable by code, you cannot have a contract that self-enforces with the block chain. The conditions set forth in contracts are extremely complex and reasonable people can differ. I cannot imagine how you would have a contract be triggered on the insolvency of a privately held corporation - good luck defining insolvency and good luck getting access to the underlying books. Copyright infringement is also a preposterous idea - the amount of semantic judgment that must be made to determine if a work is infringing is enormous. Only the very simplest of conditions - comparing numbers, checking the time, can be reliably automated, and if you are getting a lawyer to write your contracts, odds are there is substantially more complexity in the agreements than this, which is why you hired the lawyer in the first place. In addition, a fair portion of contracts that can actually be set up to work this already are - and the blockchain is not necessary. They are things like credit cards and they work pretty good without the blockchain.
---
Oh good, someone's on the ball, saves me having to write it ...
An important non-SQ truth for engineers: “Ambiguity of contracts is a *feature*, not a bug.”
Closely-focused autonomous cognitive entities (let's not start the Butlerian jihad just yet) that are engaged in detailed modelling of domain properties are at risk from complete irrelevancy if they ill-advisedly ignore influential elements from a broader context, e.g. many people fail to heed the bald, unambiguous, tell-it-like-it-is of:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
I even did my attempt at creating an identity proof, by inscribing my own name using it, and it kinda worked. The transaction id is 7a343510f4c1b1d42c9ed585b03a35e488194658642e8502f825b611e91ed408 and the OP_RETURN block has been correctly filled. It also shows in ACME, by the way, it's the second inscription after your article.
Well done, you managed to get that tx through quite a narrow window. I managed it once, when the network was quiet and my server was influential but I did most of scribbling on the testnet (also browse-able, just click on the slimcoin icon in the ACME nav bar to toggle).
It seems way too complex (which also means quite a big attack surface) but it has interesting features. I can see a similar machine, with a much lower set of operations, implemented as a plugin on Slimcoin.
The attack surface is further enlarged, unfortunately, by the Ethereum team's apparent complete unawareness of the existence of extensive research on the psychology of programming. The fundamental problems are obvious but Buterin seems insensible to them (boy, have I seen
that before) and I've learned not to waste my time. Either people will adapt their way of working to conform to its simplistic assumptions or it will permanently occupy a niche market.
(Apologies for being tediously predictable) As you might predict, I'm a lurker on
PPIG. Programming and cognition are also longstanding R&D interests of mine (art is a lifelong thing, I've found). In fact, I just came across some of the old tech papers I published inside HP from the early days when Steve and I were researching the application of cognitive science to software engineering. My ex-oppo-from-HP Steve is still interested in pursuing the topic generally in the form of “Ginger”, a syntax-neutral programming language - it's a long-term best effort (i.e. when he can find the time) project that he is leading, in conjunction with some other grizzled vets/code gurus. They hang out on a slackalike but the codebase is on github:
http://github.com/Spicery/ginger:
Ginger is our attempt to build an elegant but friendly and practical programming system. It includes a programming language, virtual machine and supporting tools.
The programming language itself is syntax-neutral. By this we mean that you can choose any of several 'pluggable' front-end syntaxes - there's one rather like Algol/Pascal, another like Javascript, another like Lisp. They all get turned into an elegant back-end XML syntax.
Ginger is a modern programming language supporting automatic memory management, object oriented programming, pervasive multiple values and a simple but powerful data loading mechanism that includes data-format conversion.
I'm the project's tame cognitive scientist. <anticipating/> I think it (looking at Ginger with an eye to using it as a TSL) is an avenue that could be explored. I recently received a notification that the Ginger effort is aiming to pick up a bit more speed so I can check whether such an effort might pique Steve's interest.
Increasing the size of OP_RETURN would be obviously necessary, but not more than 160 bytes.
Worth doing then. For clarity, this is the MAX_OP_RETURN_CHARACTERS, a limit.
Another interesting approach observed in evm is the requirement for payment to use the vm (it's in Slimcoin inscription too, as I saw). Other implementations (like the Steem blockchain) are using a "bandwidth" metaphor, but the idea is the same: limit usage to prevent abuse.
The blockchain is the ultimate and only authority, anything else can be altered. Basically, no matter what it is, if it's not got its fingers permanently trapped in the blockchain, it's free to run off with your money.
IMO, Griggs has found the only
practicable path through the symbol grounding maze, on a “render unto Caesar” basis - use the machine context to resolve issues of formal internally-consistent grounding and use the embracing human-mediated social and business context to resolve issues of informal externally-inconsistent grounding.
Cheers
Graham
