Hacker News Reader

All excellent points. I wonder if it fall in some 80/20 rule. 80% contracts may be bog standard and ripe for this kind of automation while remaining will get attention of staff. I am thinking of contracts for jobs, lease, repair works etc.

Contracts like that are almost all available as cheap templates. Smart contracts won't even solve these though. How does a smart contract solve the problem of mold in an apartment where the tenant claims it was existing and the landlord claims it was due to tenant misuse?

This is precisely the issue. Excellent example.

Easy! The little _from now on_ mandatory humidity sensor reports from the apartment! A JSON with humidity/mold data from the past 4 years is sent to the blockchain. The contract does some averages and statistics and determines that too many showers were had in 2014. Triggers a fine for the landlord's lies and dials the mold removers.

The stock price of the wall mounted humidor company go through the roof overnight. :)

I'm new to the whole area, so maybe it's my lack of knowledge of what "smart contracts" are meant to be, but is that something they are claiming to solve? I mean, how would a regular contract solve it — it wouldn't, a judge would solve it after you'd taken your landlord to court.

Are smart contracts proponents saying that they'll do away with the whole legal system, or just the solicitors' fees/time for drawing up contracts in the first place?

I presume I'd still be able to take my landlord to court for breach of contract for anything related to physical world (the bathroom is mouldy or he disputes the condition I've returned the apartment in and is withholding my deposit), but wouldn't need to pay £80 to get the contract drawn up in the first place.

And then all the 'meta' stuff, that doesn't relate to tangible things, is built-in and testable — e.g. rent cannot be increased more often than every 6 months and can only be increased by up to 15% of the current fee; at the end of the lease, the deposit minus cleaning fees should be returned within 30 days, with any interest earned.

What you are imagining are templates. They are already widespread(see LegalZoom) and almost everyone using contracts uses them for certain things.

Smart contracts are programmatically verifiable. That is why they are flawed for almost everything. They also don't allow discretion, intent, or anything that almost everyone wants to be considered in a contract.

They also wouldn't do away with lawyers fees they would just replace them with lawyers who are also programmers fees since you don't want a novice to code a smart contract since they are locked in so if its not in the contact it doesn't matter.

Smart contract proponents(well a lot of them) believe they will literally replace the whole legal system.

Some well drafted agreements will purposefully not discuss certain conditions the parties are aware may occur. Sometimes that's the only way a deal gets done. Resolving the relationship between the parties when that condition does occur is a complex dance of fitting square situations into round contract provisions and lots of phone calls.

It seems impossibly complex to predetermine the resolution of all possible human outcomes and encode it into a smart contract within a reasonable amount of time and effort.

i think the questions are:

- whether a significant share has testable conditions

- whether eventual regulatory burdens can get diminished

- whether the benefits for a use-case make it possible to introduce testable conditions (like this: https://news.ycombinator.com/item?id=13807297, or i was recently on a hackathon organised by a power provider who fears a blockchain-based marketplace will put him out of business. I was surprised how realistic they fear was. Maybe not today but alle the necessary steps are getting worked out right now)

Also to answer your concern: I think if there is a significant demand, supply will appear. Bootcamps etc are a step. But first we need a better Programming-Language. Ethereums Javascript-like Language is awful and really not useful for contracts. It's hard to impossible to automatically verify behaviour. I think it's possible to build a practical Language that's easy to prove correct.

Agreed. A turing-complete language isn't the ideal choice for smart contracts. A strongly typed ML or Haskell style language would have been a much better choice as a starting point.

That's exactly what Tezos [1] is proposing: a strongly typed language whose semantics is currently being formalized in the Coq theorem prover.

[1]: https://tezos.com/pages/tech.html

I think it's best to think "distributed computer program" when you hear "smart contract" in relation to blockchain-based code. The initial decentralized applications that will be built on blockchains will not be trying to emulate legal contracts. They will rather be focusing on things like a decentralized Dropbox, fully decentralized messaging, decentralized social networking, etc... You can make a separate argument about whether those things will succeed or not, yet they are certainly not legal code. Nick Szabo invented the term "smart contract" and his favorite example is a vending machine: you put money in, it gives you what you ask for.

Except when it doesn't, because it was loaded wrong or configured wrong or the product gets hung up in the coil or the microcontroller has an incorrect model of the hardware's current state or the power is out or what-have-you.

Perhaps this makes the metaphor even more apt than intended, however unintentionally.

I see the objective of smart contracts in finance as an augmentation of the human auditing that is already taking place. You don't need 100% of the contract to be smart in my opinion but I'm not an engineer so what do I know.

For example let's say you're at JP Morgan and are operating a $10 billion conduit ("warehouse") facility. You have a series of eligibility criteria for every originator contributing loans into the program (each of which have dozens of measurable events like average FICO, seasoning, prepayment speeds, days delinquent, etc) in addition to the vast plethora of nonfinancial terms and conditions you pointed out. Every month, these originators file a monthly remit report which in theory must be accurate (failing to do so could instantly eliminate your access to the conduit and tank your business, not something to take lightly). Right now, a banker must process all of the monthly remits for each individual facility and compare them against what was agreed to in the docs. There could be a hundred contributors to the conduit and if you happen to sit on said desk there will only be 2-3 of you managing this process. It simply can't be done.

I've spent a lot of time looking at smart contracts and block chain and have walked away a bit skeptical. There are some very real and very serious issues this in theory can address, I just think there are better ways to do it.

> Right now, a banker must process all of the monthly remits for each individual facility and compare them against what was agreed to in the docs.

OK; but what makes blockchain special for automating this as opposed to more generic software?

I'm a bit confused about the blockchain excitement. I can see it has potential for oiling transactions between unfamiliar parties. However, for big banks is it ever the case that the parties don't know each other? They'll have to agree on a common set of protocols to implement a block chain based solution, so what does it buy them over and above a more conventional API?

It's not only about whether the parties know each other, it's about how they can verify that they're all behaving according to the rules of their contract.

In multi-party scenarios, you often find intermediaries whose primary function is to act as a centralized, trusted exchange for the other parties, performing the job of the banker in the sentence you quoted. One reason this is needed is that without them, there's a lot of room for collusion between parties that deal with each other directly.

These intermediaries do currently use "more generic software", but you still need a company to run and operate that software. Blockchains can replace such companies, or at least replace one of their main reasons for existing.

In many cases, it would be possible to come up with an application-specific approach to securely and verifiably operating multi-party transactions without intermediaries, but that's not done much because it's generally just easier to use the intermediary model. Also, implementing secure decentralized transaction systems is outside of the the core competencies of the companies that need such capabilities.

Blockchains provide a generic, non-application-specific approach to implementing a secure, shared, distributed ledger, so that applications can focus on generating the transactions and not worry about the issues involved with securing a shared ledger.

OK, we replaced the baity title with representative language from the article. If someone suggests a better (more accurate and neutral) title we can change it again.

"Blockchain tech is reinventing finance and law" perhaps?

*could potentially reinvent finance and law

> Whether the conditions in a contract have been met is very often a matter of huge debate - this is what "law suits" are about.

Exactly. While laws and contract terms are written in natural language, this is an AI-complete problem. Not to say we won't solve AGI or important parts of automated legal dispute resolution, but the blockchain and even blockchain-based distributed computing is incidental.

> While laws and contract terms are written in natural language, this is an AI-complete problem.

Beautiful way of putting it.

I want to take it one step further, however:

While laws and contracts are written for human consumption this will be a problem. In the same way that DRM is always going to have to allow for users to view video with analog eyeballs and hear sound with analog ears, if laws and contracts are to be sensible to humans, they must be written in something a lot like normal language. I always argue that legalese is something more than normal language, but the point is that even in this stance, the interpreter is still a human being with semantic judgment faculties, and not a compiler or run-time interpreter.

You know why I do not anticipate that this will ever come to pass? The people in power that write laws and enforce contracts are human beings.

Yes, even if a legal subsystem is instantiated in which parties agree to abide by "programmatic contracts," the vast majority of people will not willingly use it. When an extremely precise condition is set, some party will eventually attempt to game the system (obeying the letter, but not spirit). It is in the interests of most parties to have some contract terms be ambiguous exactly as anti-gaming hedges. Ethereum's DAO debacle is a great example. It wasn't a hacker exploiting a bug, it was the system working exactly as intended.

As soon as you are in a situation where one of the parties protests that "strict compliance with the terms is not enough, common sense must apply" your situation is AI-complete.

Not only are contracts written in natural language, they are about events in the natural world. The blockchain cannot know whether you delivered 100 bushels of corn to the counterparty, what the quality of the corn was, whether you were responsible for the damage to your car or somebody else, whether the house you built is up to code, or any of the thousands of other conditions that are the subjects of everyday contracts.

You haven't heard of Law 2.0. The slow rise to financial dominance is coming to an end for the big Amlaw firms. A disruption event is on the horizon where lawyers will need to be replaced with technology/law expert hybrids who will program the legal systems which will act autonomously with as little intervention as possible. Hands on law will eventually become a thing of the past. I've been working in legal for 25 years on the IT side. I've seen it go from ALL paper to 'paper on demand'. Nearly everything is digital with ETL warehousing acting as the data conductor. The clients are fed up with $1000 an hour corporate lawyers and want another cheaper and faster solution.

It's easy to want something you can't have and wanting it a lot doesn't make it any more likely to become reality.

Where is this happening

As an individual if I want a lawyer for anything right now, I am most likely going to wind up with a complete technophobe who is barely computer literate enough to copy and paste the boilerplate legal document they make for me.

For 99% of the things I want a lawyer to do right now I'll fill out a form on LegalZoom and never see a human. Someone wrote a chatbot that helps people in NYC walk through the process of fighting their traffic citations. Automation is coming for sure.

Unless something goes wrong then you'll probably regret your canned contract for not dealing with the specifics of your needs.

Canned contracts are great and a wonderful money saver until they are needed. It's just lucky that most contracts individuals are involved in are never needed.

I genuinely cannot tell if you are trolling.

Is this some crazy manifesto, or do you actually believe this?

It sounds like a tech-crunch article on legaltech run through a markov chain.

I believe every lawyer has seen the gutting of the newly called associate class - we all know what automation is doing.

While databaseing case facts, contracts, documents, laws, jurisprudence, etc. has escalated in recent years, fundamentally a law firm is not providing those as key services - they are ancillary profit centers. One hires a contract manager to manage contracts, not a top-flight firm.

The value proposition of a law practice is dependable competence in a wide spectrum of related sub-fields. As those profit centers are commoditized and margins fall, firms will merely shift pricing, technology and talent sourcing strategy, not fall apart, because in many cases, the amount of people with competence in those fields is countably limited. Most top flight firms will be fairly straightforward with you if you ask: they don't compete on price. They compete for clients on quality of service and prestige.

The fantasy that law will act autonomously with little intervention is charming and sensible to non-practitioners. The rules are the rules, after all, what could go possibly go wrong? In practice, the answer is often 'everything'.

I agree.

Also, saying that I haven't heard of Law 2.0 is like asserting a particular developer hasn't heard of Web 2.0. It's... a strange accusation, to say the least. And one that distinguishes you as an outsider.

Block chain, smart contracts, what about the very basics? What about VCS, DRY documents, standard libraries, pop-up annotations and definitions? It seems like law has no interest in introducing standards to improve productivity and usability.

Look halfway down this article on the proposed health care replacement bill for an example of current legislative version control.

https://www.bloomberg.com/view/articles/2017-03-07/the-repub...

Version control for law drafting and other dev-like tools is something that http://www.openlawlib.org is working on.

I think there is a strong push for standard provisions, definitions, etc. The problem is that while every relationship is similar, there are always enough edge cases that forms are often only good as starting points. W/r/t to building knowledge bases for law firms, parsing existing contracts so that they are searchable and usable as sources of knowledge is a hard problem.

Here is an attempt to counter. The laws in last few centuries evolved from describing relatively simple cases to more complex ones; similarly smart contracts could grow to describe more and more verifiable conditions for automatic triggering. Additionally we may see growth of mechanisms which can be used as independent third parties - both human experts and various kinds of sensors which input can be included in the contracts.

(disclaimer I have vested interests etc)

I like to present it from the "business process" angle but after you get through the side effects of "protocolizing" things like cash and composable financial instruments, the new things we can do are currently under the umbrella of contract law. One simple example is 2-of-3 multisig for escrows.

I am a big fan of cryptocurrency, but completely agree with you about smart contracts.

From a legal perspective, as you point out, they are ridiculous, because they can't encode legally "interesting" contracts.

Many people seem to think that smart contracts can be used to replace more economic-oriented contacts, like "paying dividends to shareholders". Unfortunately here they are also useless -- the only contracts you can effectively have are zero-sum contracts; you can't have an unfunded future obligation.

Even the most basic of financial contracts, like "I'll give you $500 now and you give me $50 a month for the next 12 months", can't be effectively encoded unless I (the debtor) has $600 at the time of the issuance of the contract, so why am I taking a loan for $500? The best you can do is create a certain class of non-deliverable futures, but in the process, tying up the funds until the contract matures, and essentially preventing the use of credit in the process, which makes them useless except for toy applications.

If you read the following excellent comment by Matt Levine, you might recognise that there is huge potential in moving dividend payments and other standard transactions to the blockchain: https://www.bloomberg.com/view/articles/2017-02-17/dole-food...

We can get most of the way around problems like that, can't we?

If there's no payment, you get an immediately collectable judgment against debtor, or trigger a transfer in other payment streams (from an employer, etc.) or transfers in non-cash collateral (which, depending on the success of block chain, could eventually include block-chain titles to cars, property, other securities, etc.). Usually, banks only lend to the cash poor but asset rich, so that's not so different.

I see blockchain eventually becoming key for short term rental -- hotels, cars maybe. But the legal complexity between the law of hotel rooms and rental houses is huge.

> Even the most basic of financial contracts, like "I'll give you $500 now and you give me $50 a month for the next 12 months", can't be effectively encoded

The more interesting and viable use cases are actually more complex contracts. As a simple example consider a syndicated loan, where loan payments are distributed amongst a group. A smart contract could automate that distribution.

There are much more complex examples with multi-directional cashflows between multiple parties, where smart contracts could absolutely take care of the day to day execution of the contract.

There seems to be some confusion over the term "contract" in this context, though. Many people tend to jump to thinking it means "anything that could possibly be written in a legal contract," but the reality is that the subset of things which could be easily automated by smart contracts is enormous, worth trillions of dollars annually, even though there's a much bigger chunk that's not currently automatable.

Here's the way I see it. Part of interpreting a contract is deciding whether certain facts are true or not. This part seems hardest for a computer to do (for now), so this part can still be delegated to humans. In the law these are called "questions of fact". On the other hand, "questions of law" are the part that I think can be executed by a smart contract (once the facts are input).

You're right that many contracts are not well specified. These are "bugs" in contracts. People will have to write bug-free smart contracts. There will be a library of contract templates (github-style). This stuff already exists with contracts - lawyers have software that spit out standard forms and fills in the name of their party. And we pay them $500/hour to do it.

> On the other hand, "questions of law" are the part that I think can be executed by a smart contract (once the facts are input)

I think if you meditate about what qualifies as "taxable income" you'll be much less sure about this. There are also accountants who are paid $500/hr, and it isn't because computers can't tally a column in a spreadsheet.