Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Code is not law


First presented at the Ethereum Palo Alto meetup on August 7, 2016:

All citations and references can be found in the Notes section.

I would like to thank Ian Grigg for his constructive feedback on these slides.

  • Sé el primero en comentar

Code is not law

  1. 1. Code is not law If it was really law, it would be settled and we wouldn’t be having this conversation
  2. 2. Disclaimer • The views expressed in this presentation are solely my own and do not necessarily represent the views of my employer or any organization I advise • I neither own nor have any trading position on any cryptocurrency • I am not a lawyer
  3. 3. Why does C-i-n-L matter? • When validating transactions and code on a network: • How do we decide who has legal standing when something forks or breaks? • How do we decide who is liable when a hack or mistake occurs? • How do we decide who bears responsibility if a block reorg or orphan occurs? • How do we decide who is responsible for recourse and restitution? • How do we decide who has a contractual relationship to fulfill validating duties? • How do we decide who can enforce the rulings of disputes? • Or in short: when the system doesn’t behave like it was expected to, how do we decide who is at fault?
  4. 4. If the cryptocurrency community could achieve governance / enforcement algorithmically, we already would have done that. We're having this meeting today because something broke. What now?
  5. 5. Public / anarchic chains • Intentionally lack: • Terms of Service; End-User License Agreement; service-level agreement; consumer protections; customer service • Customer service handled solely via upvoting and retweeting on social media • They lack these contractual hooks because any such artifact in an anarchic chain leads to some "controller" who can be shut down • And because these systems were specifically designed around pseudonymous interactions: there are no linkages to external identification systems and no hooks into the traditional legal system • This may be desirable to specific groups of consumers however empirically the user experience (UX) for unsavvy users is extremely poor and filled with friction
  6. 6. What does this look like in practice?
  7. 7. Examples of off-chain governance / resolution • The DAO attack / counter attack / counter counter attack • On June 18, 2016 over 3.64 million ether (~$55 million) was drained from The DAO into a child DAO • Solutions carried out: massive off-chain social media debates leading to a hard fork • “Accidental” fees to miners • On August 28, 2013 a bitcoin user sent a 200 bitcoin fee ($23,518) that was processed by ASICMiner • Solution carried out: complaints on reddit leading to a purported refund • On April 25, 2015 a BitGo user, due to a software glitch, accidentally sent 85 bitcoins ($19,197) as a mining fee to AntPool • Solution carried out: complaints on reddit leading to a refund • On September 11, 2015 another user sent 4.6 bitcoins (worth $1,113) as a fee to AntPool • Solution carried out: Bitmain, the parent company, once again returned the fee to the user • On April 27, 2016 a user sent a 291 bitcoin fee (~ $137,000) that was packaged by BitClub Network, a pool in the Netherlands • Someone claiming to be a representative from BitClub claimed on Twitter they were trying to reach out and find the user but it is unclear if this was all just a ruse (part of a MLM scam?); half the fee (146 bitcoiions) was later donated to The Bitcoin Foundation
  8. 8. Cont’d • Value overflow incident / CVE-2010-5139 • On August 15, 2010 block 74638 contained 184.4 billion bitcoins • Solution: Hard fork / soft fork (depends on who you talk to) • On March 11, 2013 an accidental fork occurred and 24 blocks (600 bitcoins) were eventually orphaned (version 0.7 and version 0.8) • Solution: coordination on IRC via mining pools, exchanges, and developers • Losers: BTC Guild (which mined some of the blocks), OKPay (hit by a double-spend) • Bitfinex hack (among many other hacks of unregulated exchanges) • On August 2, 2016 at least 119,756 bitcoins (~$66 million) were stolen* from Bitfinex • Solutions carried out: coordination with off-chain law enforcement; massive social media debates; socialized losses of 36% across all accounts including non-bitcoin assets
  9. 9. A (brief) anatomy of a hack The first 10 blocks that included transactions from the August 2016 Bitfinex hack were built into blocks by the following pools (listed chronologically): • BTCC Pool (mined the first block of the hack) • AntPool • ViaBTC • AntPool • BTCC Pool • BW Pool • Bitfury • ViaBTC • F2Pool • F2Pool
  10. 10. Restitution? • 9 out of the first 10 blocks that included the Bitfinex coins were built by pools operating in a country that has different data privacy / property laws than those in the West • How does operating in this jurisdiction (China) impact the (future) answers from the same questions on slide #3? (i.e., laws are different everywhere) • Can mining pool operators be held liable for some damages, especially as news becomes more widespread? • What kind of risk monitoring will the market and regulators place onto the market? • E.g., via analytics / data science you can see the exact transactions just by looking at the blockchain • There are about 10 companies that now provide this kind of risk / threat modeling to compliance teams and law enforcement
  11. 11. Ethereum hard fork • On July 20, 2016 – multiple stakeholders in the Ethereum ecosystem initiated a purposeful hard fork at block height 1920000 • Both block 1920000 and block 1920001 were mined by • Sidenote: is also a prominent pool for Bitcoin • If financial instruments from a regulated institution were sent to miners during the transition phase and are no longer accessible because the instruments were sent to the “deprecated” chain, who is to blame and bears responsibility? • Which party is supposed to provide compensation and restitution?
  12. 12. What happened after the fork?
  13. 13. Common theme of anarchic chains: governance and dispute resolution continues to be handled off-chain via social media and traditional legal infrastructure (e.g., courts)
  14. 14. Because of the intentional lack of ties into legal infrastructure, anarchic / public blockchains operate on the premise of caveat emptor
  15. 15. This creates a complicated, friction-full experience for unsavvy users
  16. 16. What if you link the code to legal prose (and vice-versa)?
  17. 17. Let’s review a few alternatives • Chains, ledgers, and code tied directly into legal infrastructure and institutions by default are under development • Examples of alternatives: • Ricardian Contracts • Barclays: Smart Contract Templates • Eris: dual integration • Corda • Sidebar: Robert Sams and his definition of ‘distributed ledgers’ • See also: CommonAccord as well as Tezos – a self-amending chain
  18. 18. Ricardian Contract / Ian Grigg • A single document that is • a) a contract offered by an issuer to holders, • b) for a valuable right held by holders, and managed by the issuer, • c) easily readable by people (like a contract on paper), • d) readable by programs (parsable like a database), • e) digitally signed, • f) carries the keys and server information, and • g) allied with a unique and secure identifier.
  19. 19. Josh Stark; and Barclays • Proposed definitions which are distinctly different than what C-i-L proponents make: • “smart legal contracts” • where the agreement is a legal agreement, which is then capable of automatic execution in software • “smart contract code” • which may not necessarily be linked to a formal legal agreement, yet must be executed automatically
  20. 20. Corda / Richard Brown • Our starting point is individual agreements between firms (“state objects”, governed by “contract code” and associated “legal prose”). We reject the notion that all data should be copied to all participants, even if it is encrypted. • Secondly, our focus is on agreements: the need to link to legal prose is considered from the start. We know there will still always be some disputes and we should specify right up front how they will be resolved. • Thirdly, we take into the account the reality of managing financial agreements; we need more than just a consensus system. We need to make it easy to write business logic and integrate with existing code; we need to focus on interoperability. And we need to support the choreography between firms as they build up their agreements.
  21. 21. Why should you care about how other platforms are handling legal prose and contract code?
  22. 22. Tldr: if you don't say up front how problems will be resolved, then anything goes ... which means you eventually end up in court which is a bit self- defeating for an anarchic chain. To solve this problem a community needs to state up front how the disputes will be resolved in the contract itself.
  23. 23. What does this have to do with Ethereum or other anarchic chains?
  24. 24. ETH and ETC and others down the line • Because there is no de jure authority in an anarchic chain, no one can legitimately claim which chain is the “right” one • As a consequence, lacking ties into legal infrastructure, there is no recognized external authority that can legitimately claim which fork of Bitcoin or Ethereum is the ‘One True Chain.’ • Instead there are other attempts to attest to which chain is supposed to be the de facto chain: • E.g., via PoW / PoS, the chain code, the smart contract, the community, the Foundation, the devs and other stakeholders.
  25. 25. Cont’d • In other words, public blockchains, contrary to the claims on social media, are not “law” because they do not actually tie into the legal infrastructure which they were purposefully designed to skirt • They do not handle disputes on-chain: leaving it to a nebulous, ill-defined handwavy governance process pitting miners versus developers versus users versus commercial companies and so forth • This is visible during the current ETH versus ETC debates as well as the Bitcoin Core versus Bitcoin Classic debates (e.g., private conferences for miners, sock puppets, censorship)
  26. 26. Any potential solutions for the Ethereum community?
  27. 27. Ian Grigg’s suggestion for Ethereum 1. there is a chain agreement to which all abide. 2. the chain agreement says in prose that ‘we accept smart contracts as binding.’ 3. proper smart contracts include legal prose that refers all T&C to the code. 4. dispute resolution is set in 1 and can be overridden in 3. 5. the no-brainer dispute resolution is Arbitration before an arbitrator chosen under community-written rules. Once agreed, Arbitration provides substantial protection from civil claims "to arbitration you go!" and also provides the gravitas to order a hard fork. It can also accommodate psuedonyms.
  28. 28. Conclusions • Empirically, mistakes can and do continue to be made on public / anarchic chains but they lack any native on-chain mechanism to directly enforce / govern off-chain actions and data • As a result: if you are involved in above-board commercial activity, attempting to rectify and hold those liable for their contractual responsibilities is difficult on anarchic chains • If your assumption is that traditional legal infrastructure and identities may be required and used during the commercial transaction then permissioned ledgers / “archy” chains are fit-for- purpose for your operation
  29. 29. Contact