Diese Präsentation wurde erfolgreich gemeldet.

Color around Dead Token Litigation

688 Aufrufe

Veröffentlicht am

First presented at Anderson Kill's 1st Annual Blockchain and Virtual Currency Conference on May 23, 2018 in New York City.

Note: my presentation provided additional color to the key topic presented earlier by Stephen Palley who actually defines "dead token litigation."

See: https://www.andersonkill.com/Event-Details/EventID/1212

Veröffentlicht in: Bildung
  • Als Erste(r) kommentieren

Color around Dead Token Litigation

  1. 1. Whoops, you made a mistake and now it’s on a blockchain
  2. 2. What not to do
  3. 3. Making promises you cannot keep
  4. 4. From the “ICO Whitepaper Whitepaper” on June 6, 2017:
  5. 5. Fast forward to December 11, 2017... … the “Munchee Order” from the SEC
  6. 6. Overhyping and exaggerating didn’t start with ICOs, just rewind to bitcoin memes in 2014
  7. 7. That didn’t work out...
  8. 8. Rumor mongering is still part and parcel of how coin-focused VC’s drum up attention for deal flow to their funds
  9. 9. This event didn’t actually happen
  10. 10. Or publicly bragging about something you may not have
  11. 11. Claiming to be a coin creator… but analytics say no
  12. 12. Someone always cheats in the cartel
  13. 13. Putting lipstick on a pig… or renaming a company in this case
  14. 14. What are the step-by-step mechanics of this?
  15. 15. Subpoenacoin era: 2017 – to present
  16. 16. Arrestedcoin era: 2018 -->
  17. 17. In 2014 Ray Dillinger attempted a thankless task
  18. 18. Necronomicon
  19. 19. Dillinger’s cataloguing legacy lives on
  20. 20. At some point, we might even begin the era of “dead token litigation.” While not dead (yet), there is an interesting lawsuit that was filed earlier in April 2018.
  21. 21. What about Nano? tldr: a significant portion of Nano (formerly Raiblocks) were being stored at an Italian exchange called BitGrail. BitGrail got “hacked” and one of the plaintiffs hired a US law firm (Silver Miller). Part of the attempted recourse in the class-action suit is to require the developers to coordinate an emergency chain “roll back.”
  22. 22. These anecdotes, social media screenshots, and actual court cases are just the tip of the iceberg, which leads to the conclusion...
  23. 23. Code is not law 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 and extract recourse?
  24. 24. Questions or comments? Contact: tim@postoaklabs.com 37