8 changed files with 248 additions and 665 deletions
--- a/flake.lock
+++ b/flake.lock
@ -5,11 +5,11 @@
        "nixpkgs-lib": "nixpkgs-lib"
      },
      "locked": {
-        "lastModified": 1763759067,
+        "lastModified": 1733312601,
-        "narHash": "sha256-LlLt2Jo/gMNYAwOgdRQBrsRoOz7BPRkzvNaI/fzXi2Q=",
+        "narHash": "sha256-4pDvzqnegAfRkPwO3wmwBhVi/Sye1mzps0zHWYnP88c=",
        "owner": "hercules-ci",
        "repo": "flake-parts",
-        "rev": "2cccadc7357c0ba201788ae99c4dfa90728ef5e0",
+        "rev": "205b12d8b7cd4802fbcb8e8ef6a0f1408781a4f9",
        "type": "github"
      },
      "original": {
@ -20,11 +20,11 @@
    },
    "nixpkgs": {
      "locked": {
-        "lastModified": 1764517877,
+        "lastModified": 1734424634,
-        "narHash": "sha256-pp3uT4hHijIC8JUK5MEqeAWmParJrgBVzHLNfJDZxg4=",
+        "narHash": "sha256-cHar1vqHOOyC7f1+tVycPoWTfKIaqkoe1Q6TnKzuti4=",
        "owner": "NixOS",
        "repo": "nixpkgs",
-        "rev": "2d293cbfa5a793b4c50d17c05ef9e385b90edf6c",
+        "rev": "d3c42f187194c26d9f0309a8ecc469d6c878ce33",
        "type": "github"
      },
      "original": {
@ -36,17 +36,14 @@
    },
    "nixpkgs-lib": {
      "locked": {
-        "lastModified": 1761765539,
+        "lastModified": 1733096140,
-        "narHash": "sha256-b0yj6kfvO8ApcSE+QmA6mUfu8IYG6/uU28OFn4PaC8M=",
+        "narHash": "sha256-1qRH7uAUsyQI7R1Uwl4T+XvdNv778H0Nb5njNrqvylY=",
-        "owner": "nix-community",
+        "type": "tarball",
-        "repo": "nixpkgs.lib",
+        "url": "https://github.com/NixOS/nixpkgs/archive/5487e69da40cbd611ab2cadee0b4637225f7cfae.tar.gz"
        "rev": "719359f4562934ae99f5443f20aa06c2ffff91fc",
        "type": "github"
      },
      "original": {
-        "owner": "nix-community",
+        "type": "tarball",
-        "repo": "nixpkgs.lib",
+        "url": "https://github.com/NixOS/nixpkgs/archive/5487e69da40cbd611ab2cadee0b4637225f7cfae.tar.gz"
        "type": "github"
      }
    },
    "root": {
--- a/flake.nix
+++ b/flake.nix
@ -25,13 +25,10 @@
            build = pkgs.writeShellScriptBin "build"
            ''
              pandoc -t revealjs \
                -V revealjs-url=https://unpkg.com/reveal.js \
                --from markdown+yaml_metadata_block+link_attributes \
                -H src/header.html \
                -o public/index.html \
                -s \
                --slide-level 3 \
                --toc \
                src/index.md
              '';
            serve = pkgs.writeShellScriptBin "serve" 
@ -47,7 +44,7 @@
          shellHook = ''
            echo 1>&2 "Welcome to the development shell!"
          '';
-          name = "devshell";
+          name = "glossary-devshell";
          packages = [
            pkgs.pandoc
            pkgs.caddy
--- a/public/assets/does-it-scale.jpg
+++ b/public/assets/does-it-scale.jpg
--- a/public/assets/logo.png
+++ b/public/assets/logo.png
--- a/public/favicon.ico
+++ b/public/favicon.ico
--- a/public/index.html
+++ b/public/index.html
@ -3,12 +3,12 @@
 <head>
  <meta charset="utf-8">
  <meta name="generator" content="pandoc">
-  <title>Konduit.channel</title>
+  <title>Cardano Lightning</title>
  <meta name="apple-mobile-web-app-capable" content="yes">
  <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui">
-  <link rel="stylesheet" href="https://unpkg.com/reveal.js/dist/reset.css">
+  <link rel="stylesheet" href="https://unpkg.com/reveal.js@^4//dist/reset.css">
-  <link rel="stylesheet" href="https://unpkg.com/reveal.js/dist/reveal.css">
+  <link rel="stylesheet" href="https://unpkg.com/reveal.js@^4//dist/reveal.css">
  <style>
    .reveal .sourceCode {  /* see #7635 */
      overflow: visible;
@ -29,24 +29,21 @@
    }
    .display.math{display: block; text-align: center; margin: 0.5rem auto;}
  </style>
-  <link rel="stylesheet" href="https://unpkg.com/reveal.js/dist/theme/black.css" id="theme">
+  <link rel="stylesheet" href="https://unpkg.com/reveal.js@^4//dist/theme/black.css" id="theme">
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  <link href="https://fonts.googleapis.com/css2?family=JetBrains+Mono:ital,wght@0,100..800;1,100..800&display=swap" rel="stylesheet">
  <style>
  body {
-    font-family: "JetBrains Mono", monospace;
+   font-family:  ui-sans-serif;
  }
  .reveal h1,  .reveal h2,  .reveal h3,  .reveal h4,  .reveal h5,  .reveal h6 
  {
-    font-family: "JetBrains Mono", monospace;
+    font-family:"TruenoSemiBold", "ui-sans-serif";
  }
  @font-face{
-    font-family: "JetBrains Mono", monospace;
+    font-family:"TruenoSemiBold";
    src:local("TruenoSemiBold"),
    url("./fonts/TruenoSemiBold.woff2") format("woff2");
    font-weight: 600;
  }
  .black h2 {
    background-color: #020210;
  }
@ -57,6 +54,7 @@
  .reveal .slides p {
    margin: 2rem 0;
    text-align:left;
  }
  .reveal .slides blockquote > p {
@ -70,398 +68,177 @@
    <div class="slides">
 <section id="title-slide" data-background-image="./assets/logo.png" data-background-opacity="0.3" data-background-size="contain">
-  <h1 class="title">Konduit.channel</h1>
+  <h1 class="title">Cardano Lightning</h1>
-  <p class="subtitle">[A bunch of ideas in 15mins]</p>
+  <p class="subtitle">Permissionless, near instant, highly scalable</p>
 </section>
 <section id="TOC">
 <nav role="doc-toc"> 
 <h2 id="toc-title">toc</h2>
 <ul>
 <li><a href="#/what-is" id="/toc-what-is">What is …</a>
 <ul>
 <li><a href="#/konduit" id="/toc-konduit">Konduit?</a></li>
 <li><a href="#/bitcoin-lightning" id="/toc-bitcoin-lightning">Bitcoin
 Lightning?</a></li>
 <li><a href="#/the-problem" id="/toc-the-problem">The problem?</a></li>
 <li><a href="#/the-ask" id="/toc-the-ask">The ask</a></li>
 </ul></li>
 <li><a href="#/lightning-bln" id="/toc-lightning-bln">Lightning /
 BLN</a>
 <ul>
 <li><a href="#/overview" id="/toc-overview">Overview</a></li>
 <li><a href="#/hops" id="/toc-hops">Hops</a></li>
 <li><a href="#/htlcs" id="/toc-htlcs">HTLCs</a></li>
 <li><a href="#/routes" id="/toc-routes">Routes</a></li>
 </ul></li>
 <li><a href="#/cardano-lightning" id="/toc-cardano-lightning">Cardano
 Lightning</a>
 <ul>
 <li><a href="#/pitch" id="/toc-pitch">Pitch</a></li>
 </ul></li>
 <li><a href="#/subbit.xyz" id="/toc-subbit.xyz">Subbit.xyz</a>
 <ul>
 <li><a href="#/trustless-subscriptions"
 id="/toc-trustless-subscriptions">Trustless<sup>*</sup>
 subscriptions</a></li>
 <li><a href="#/iou" id="/toc-iou">IOU</a></li>
 <li><a href="#/unidirectionality-boons"
 id="/toc-unidirectionality-boons">Unidirectionality boons</a></li>
 <li><a href="#/overhead" id="/toc-overhead">Overhead?</a></li>
 </ul></li>
 <li><a href="#/konduit-1" id="/toc-konduit-1">Konduit</a>
 <ul>
 <li><a href="#/subbit-htlcs" id="/toc-subbit-htlcs">Subbit +
 HTLCs</a></li>
 <li><a href="#/keep-the-boons" id="/toc-keep-the-boons">Keep the
 boons</a></li>
 <li><a href="#/other-deets" id="/toc-other-deets">Other deets</a></li>
 </ul></li>
 <li><a href="#/demo" id="/toc-demo">Demo ?!</a>
 <ul>
 <li><a href="#/soon" id="/toc-soon">Soon™</a></li>
 </ul></li>
 <li><a href="#/ideas" id="/toc-ideas">Ideas</a>
 <ul>
 <li><a href="#/ideas-inner" id="/toc-ideas-inner">ideas inner</a></li>
 </ul></li>
 </ul>
 </nav>
 </section>
 <section>
-<section id="what-is" class="title-slide slide level2">
+<section id="problem" class="title-slide slide level2">
-<h2>What is …</h2>
+<h2>Problem</h2>
 </section>
-<section id="konduit" class="slide level3">
+<section id="payments" class="slide level3">
-<h3>Konduit?</h3>
+<h3>Payments</h3>
 <ul>
 <li>A fundamental part of all commerce: payment.</li>
 </ul>
 </section>
 <section id="who" class="slide level3">
 <h3>Who?</h3>
 <p>There are three parties involved in a payment</p>
 <ul>
 <li>Consumer (ie payer)</li>
 <li>Provider (ie payee)</li>
 <li>Facilitator</li>
 </ul>
 <p>All of us are consumers, some are providers, a few are
 facilitators.</p>
 </section>
 <section id="what-users-want" class="slide level3">
 <h3>What users want</h3>
 <blockquote>
-<p>A Cardano to Bitcoin Lighting Pipe</p>
+<p>Users want secure, fast, low cost transactions</p>
 </blockquote>
-<!-- 
+<p>However participants have different priorities, <em>eg</em></p>
    The first question is then "what is Bitcoin Lightning"
 -->
 </section>
 <section id="bitcoin-lightning" class="slide level3">
 <h3>Bitcoin Lightning?</h3>
 <p>… a payment protocol built on bitcoin intended to enable fast
 transactions among participating nodes and has been proposed as a
 solution to the bitcoin scalability problem.</p>
 <!--
    A slight abbreviation of the wiki entry 
    A slightly trucated opening lines from the wikipedia page. 
    Whoever provided or endorsed this version clearly thinks this point is moot.
 -->
 </section>
 <section id="the-problem" class="slide level3">
 <h3>The problem?</h3>
 <div
 style="display:flex;flex-direction:row;justify-content: space-around; align-items: center;">
 <p><img data-src="./assets/does-it-scale.jpg" /></p>
 <ul>
-<li>Scalability</li>
+<li>Consumers want ease-of-use</li>
-<li>Finality</li>
+<li>Providers want fast confirmation</li>
-<li>Tx fees</li>
+<li>Facilitators need to handle at scale</li>
 </ul>
 </div>
 <!-- 
    The classic complaints about (real) L1s
    You cannot walk into a cafe, say, and purchase a coffee on the L1.
    Ok its probably fine (we have no traffic, long rollbacks don't happen. wink emoji).
    But it shouldn't make sense: We cannot have all the nodes handling everyone's morning coffee purchase. 
    It does not scale.
    On finality, we arn't really competing with web2.
    Payment providers can retroactively deny payments (no source).
    We, Cardano, have the same problem. 
    One route to remedy: don't reinvent the wheel, piggy back on their wheel. 
 -->
 </section>
 <section id="the-ask" class="slide level3">
 <h3>The ask</h3>
 <p>Can we go from Cardano to BLN?</p>
 <!-- 
    Lightning exists. It has some level of adoption. 
    Some cafes accept lighting payments. 
    Could we open this up to ada holders?! 
    Not for the merchants necessarily, but for the consumers.
 -->
 </section></section>
 <section>
 <section id="lightning-bln" class="title-slide slide level2">
 <h2>Lightning / BLN</h2>
 <!-- 
    A lightning round on Lightning network
 -->
 </section>
 <section id="overview" class="slide level3">
 <h3>Overview</h3>
 <ul>
 <li>A network of two party channels</li>
 <li>L1: Each channel is “underwritten” by locked funds</li>
 <li>L2: exchanging messages alters how and who can claim these
 funds</li>
 </ul>
 <!-- 
    Lightning is a network of two party channels.
    Each channel corresponds to a utxo holding the funds on the L1 that underwrite L2 messages. 
    For example you could have a channel with the coffee shop,
    and for each morning coffee is paid for via an L2 message.
    Immediate questions:
    - Do i need a channel with everyone I want to pay? If so whats the point?
    - How is this a network?
    An asside: This is a super interesting setup. 
    Subscription based services are "handwave" north of a trillion dollars and growing.
 -->
 </section>
 <section id="hops" class="slide level3">
 <h3>Hops</h3>
 <ul>
 <li>2 channels: Alice &lt;-&gt; Bob; Bob &lt;-&gt; Charlie</li>
 <li>Alice ~&gt; Charlie ?</li>
 <li>Alice ~&gt; Bob ~&gt; Charlie.</li>
 <li>Problem: Naive hops require trust</li>
 </ul>
 <!--
    How to make a set of channels a network. 
    Shoe horning in another idea: 
    The topology of our networks should reflect their use case. 
    The L1 makes it as easy for anyone to pay anyone: 
    a very flexible basis, but this is basically nobodies use case. 
    I'm far more likely to pay somone i've already paid, than someone at random. 
 -->
 </section>
 <section id="htlcs" class="slide level3">
 <h3>HTLCs</h3>
 <ul>
 <li>Trustless hops</li>
 <li>Hashed TimeLocked Contract</li>
 <li>Parameterized by <code>(timeout, lock, payer, payee)</code></li>
 <li>Two spend pathways:
 <ul>
 <li>Ok: Signed by <code>payee</code>; Before <code>timeout</code>; Has
 <code>secret</code></li>
 <li>Ko: Signed by <code>payer</code>; After <code>timeout</code></li>
 </ul></li>
 <li>Note: <code>hash(secret) == lock</code></li>
 </ul>
 <!--
    Enter HTLCs 
    This is a basic implementation of an HTLC. 
    In practice we want to reuse the same locked funds multiple times, 
    and for values, timeouts, and locks that are not apriori known.
    But ultimately, its some version of this. 
    A warning: the term HTLC is used to mean the "contract", the output at the contract, the would be output in tx not submitted, 
    and the general concept illustrated
 -->
 </section>
 <section id="routes" class="slide level3">
 <h3>Routes</h3>
 <ul>
 <li>C ~&gt; A : Invoice including lock.</li>
 <li>A ~&gt; B : HTLC with timeout <code>T</code> and lock</li>
 <li>B ~&gt; C : HTLC with timeout <code>T - delta</code> and lock</li>
 <li>C ~&gt; B : Secret</li>
 <li>B ~&gt; C : Commitment to pay (no htlc)</li>
 <li>B ~&gt; A : Secret</li>
 <li>A ~&gt; B : Commitment to pay (no htlc)</li>
 </ul>
 <!--
    This is the message flow, at least for the happy path. 
    We need to unpack the unhappy branch on each line.
    "What if the message never arrives" (sent or otherwise).
    Now we know how lightning works. 
    We have avoided saying what these commitments look like. 
    Implementation detail.
    We haven't said anything about finding viable routes.
    (Essentially magic.)
    But we've said very little about bitcoin. 
    Great so we should just implement lightning on Cardano! 
 -->
 </section></section>
 <section>
 <section id="cardano-lightning" class="title-slide slide level2">
 <h2>Cardano Lightning</h2>
 </section>
 <section id="pitch" class="slide level3">
 <h3>Pitch</h3>
 <ul>
 <li>Do Lightning but on Cardano</li>
 </ul>
 <div class="fragment">
 <ul>
 <li>And better</li>
 </ul>
 <!--
    Why? Its a fun project.
    Lightning is too complicated.
    Its hard to reason about, its hard to implement, its hard to adapt. 
    Lightning has two key problems: 
        - All nodes are full nodes (anyone can route, and has to run a full node)
        - Fund drift
    Both are manifestations that lightning topology does not reflect the problematic. 
    We have good reason to think we can do much better on these fronts using Cardano.
    Recall that the original ask is to get from Cardano to BLN (not back again)
    Every feature comes at some cost.
    Full lightning is not cheap (it also doesn't yet exist). 
    The CL project is happening and is the reason I'm here, but this was not the ask.
    One more digression: Why was invited to build CL?
 -->
 </div>
 </section></section>
 <section>
 <section id="subbit.xyz" class="title-slide slide level2">
 <h2>Subbit.xyz</h2>
 </section>
 <section id="trustless-subscriptions" class="slide level3">
 <h3>Trustless<sup>*</sup> subscriptions</h3>
 <ul>
 <li>Alice wants to subscribe to Bob’s service</li>
 <li>Alice locks funds on the L1; Bob sees</li>
 <li>Each request Alice includes an “IOU”; Bob verifies and responds</li>
 <li>At Bob’s leisure, he claims (<code>subs</code>) funds owed</li>
 </ul>
 <p>An embarrassingly simple L2</p>
 <!--
    At any point either party can stop participating.
    Moreover, they are able to claim the funds demonstrably theirs 
    (perhaps after a waiting period). 
    The astricks is to indicate that Bob may cheat Alice in his response. 
    Alice ought to stop using the service as soon as this is the case. 
 -->
 </section>
 <section id="iou" class="slide level3">
 <h3>IOU</h3>
 <pre class="cddl"><code>amount = int
 signature = bytestring .size 64 
 iou = #6.121( [ amount, signature ] )</code></pre>
 <pre class="cddl"><code>tag = bytestring
 message = #6.121( [ tag, amount ] ) </code></pre>
 <!--
    Each channel has a `tag`. This allows Alice to use her key for multiple channels.
    This is it.
    Bob presents this to the L1 and takes funds owed.
    Note this doesn't close the channel, and the action is ~idempotent. 
    That is, if Bob reused the same IOU he'd not be able to extract any more funds. 
 -->
 </section>
 <section id="unidirectionality-boons" class="slide level3">
 <h3>Unidirectionality boons</h3>
 <ul>
 <li>Alice’s safety is not dependent on chain liveness</li>
 <li>Bob’s sub is unilateral. No contestation.</li>
 </ul>
 </section>
-<section id="overhead" class="slide level3">
+<section id="existing-systems-12" class="slide level3">
-<h3>Overhead?</h3>
+<h3>Existing systems (1/2)</h3>
 <ul>
-<li>Alice (client) must remember their keys</li>
+<li>Cash: Permissionless, instant, scalable-ish (lots of people can use
-<li>Must be able to produce a signature</li>
+it at the same time, but only to pay people near them), questionable
-<li>Maybe some other state (&lt; 100 bytes) or 2 trips.</li>
+security (fraud happens).</li>
 <li>Bank transfer: Permissioned, some instant others very slow,
 scalable.</li>
 <li>Contactless/ Card: Permissioned, near instant, scalable</li>
 </ul>
 </section>
 <section id="section" class="slide level3">
 <h3>… (2/2)</h3>
 <ul>
 <li>Decentralised Ledger *: permissionless, maybe fast or scalable but
 generally not both.</li>
 </ul>
 <p><span style="font-size: small"> * There are many different designs of
 decentralised ledger, each with different choices and trade-offs. Some
 permissioned, some more decentralised than others, some faster,
 <em>etc</em>. </span></p>
 </section>
 <section id="market-size" class="slide level3">
 <h3>Market size</h3>
 <ul>
 <li><p>Contactless transactions will reach $11 trillion by 2027 <span
 style="font-size: small"> source : Juniper Research </span></p></li>
 <li><p>Market Cap for crypto : &gt; $3 trillion <span
 style="font-size: small"> source : coinmarketcap.com (Dec 2024)
 </span></p></li>
 </ul>
 </section>
 <section id="intersection" class="slide level3">
 <h3>Intersection</h3>
 <blockquote>
 <p>Can we have contactless like experience but permissionless.</p>
 </blockquote>
 </section>
 <section id="problem-statement" class="slide level3">
 <h3>Problem statement</h3>
 <p>We want a payment system that is:</p>
 <ol type="1">
 <li>Permissionless and secure</li>
 <li>Near instant</li>
 <li>Highly scalable</li>
 </ol>
 </section>
 <section id="bitcoin-lightning-network" class="slide level3">
 <h3>Bitcoin Lightning Network?</h3>
 <p>In a lightning network:</p>
 <ul>
 <li>The network is fundamentally a set of channels, not a shared
 ledger.</li>
 <li>There is no need to reach consensus, or globally broadcasting
 state.</li>
 <li>Payments are routed across channels by participants.</li>
 <li>Speed of payment isn’t a global property, but a more local one.</li>
 </ul>
 <p>BLN does this and is the closest to meeting our aims.</p>
 </section>
 <section id="problems-with-bln" class="slide level3">
 <h3>Problems with BLN</h3>
 <p>However it has some issues:</p>
 <ul>
 <li>Large technical and resource overhead to use. Every user must run a
 node.</li>
 <li>Difficult to efficiently manage capital. Liquidity is required to
 enable payments to be routed across a network. Moving capital between
 channels requires multiple transactions.</li>
 </ul>
 </section></section>
 <section>
-<section id="konduit-1" class="title-slide slide level2">
+<section id="solution" class="title-slide slide level2">
-<h2>Konduit</h2>
+<h2>Solution</h2>
 <!-- 
    Ok. Back on topic: how are we going to meet the ask
 -->
 </section>
 <section id="subbit-htlcs" class="slide level3">
 <h3>Subbit + HTLCs</h3>
 <p>Not IOUs, but cheques + squashes</p>
 <pre class="cddl"><code>cheque_body = [index, amount, timeout, lock]
 cheque = [cheque_body, signature]
 excludes = [* index]
 squash_body = [amount, index, excludes] 
 squash = [squash_body, signature]</code></pre>
 <!-- 
    The role is essentially the same. 
    The signature is of a message that is a mild reworking of the version in subbit.
    On a happy path, a cheque is made, a secret learned and shared, and the cheque is squashed. 
 -->
 </section>
-<section id="keep-the-boons" class="slide level3">
+<section id="cardano-lightning" class="slide level3">
-<h3>Keep the boons</h3>
+<h3>Cardano Lightning</h3>
 <ul>
 <li>Alice still doesn’t need chain liveness</li>
 <li>Bob unilateral subs now have the evidence:</li>
 </ul>
 <pre class="cddl"><code>unlocked = [cheque_body, signature, secret]
 receipt = [squash, [*unlocked]] </code></pre>
 <!-- 
    On the happy path the list of unlockeds will be empty.
    But maybe Alice goes offline before bob learns the secret. 
 -->
 </section>
-<section id="other-deets" class="slide level3">
+<section id="design" class="slide level3">
-<h3>Other deets</h3>
+<h3>Design</h3>
 <ul>
-<li>Token free design</li>
+<li>A perturbation on BLN: its a Lightning Network</li>
-<li>“Batch” txs are first class</li>
+<li>Focused on addressing the key technical blockers to it being used as
-<li>“Mutual” txs are first class and invoke no futher verification steps
+a day-to-day payment system.</li>
-(beyond <code>required_signers</code>)</li>
+</ul>
 </section>
 <section id="tailored-nodes" class="slide level3">
 <h3>Tailored Nodes</h3>
 <p>CL recognises a diversity users have a diversity of needs.</p>
 <ul>
 <li>For consumers we have a lightweight node, minimal resources, and
 runs on their phone.</li>
 <li>Some providers might be happy running their own servers, others
 wont. There’s a flexible CL node + SDK to suit a full spectrum of
 usecases.</li>
 </ul>
 </section>
 <section id="leveraging-cardano" class="slide level3">
 <h3>Leveraging Cardano</h3>
 <ul>
 <li><p>Cardano’s more powerful scripting language allows us to achieve
 more with less.</p></li>
 <li><p>In particular we can optimize capital allocation for
 nodes.</p></li>
 <li><p>For the facilitators, we have a node for efficient handling of
 many channels concurrently. Those with capital and wanting to put it to
 use become the facilitators. They receive income on the service they
 provide, each payment they facilitate in routing.</p></li>
 </ul>
 <!-- 
 -->
 </section></section>
 <section>
-<section id="demo" class="title-slide slide level2">
+<section id="team" class="title-slide slide level2">
-<h2>Demo ?!</h2>
+<h2>Team</h2>
 </section>
-<section id="soon" class="slide level3">
+<section id="section-1" class="slide level3">
-<h3>Soon™</h3>
+<h3></h3>
 </section></section>
 <section>
 <section id="ideas" class="title-slide slide level2">
 <h2>Ideas</h2>
 </section>
 <section id="ideas-inner" class="slide level3" style="display:none">
 <h3 style="display:none">ideas inner</h3>
 <ul>
-<li>The topology of our networks should reflect their usage</li>
+<li><span class="citation" data-cites="waalge">@waalge</span></li>
-<li>Cardano’s super power: verify signatures of arbitrary data</li>
+<li><span class="citation" data-cites="paluh">@paluh</span></li>
-<li>All dapps should be L2s</li>
+<li><span class="citation" data-cites="nhenin">@nhenin</span></li>
 <li>A dapp devs main role is to keep user’s from others</li>
 <li>You don’t need tokens</li>
 </ul>
 </section></section>
    </div>
  </div>
-  <script src="https://unpkg.com/reveal.js/dist/reveal.js"></script>
+  <script src="https://unpkg.com/reveal.js@^4//dist/reveal.js"></script>
  <!-- reveal.js plugins -->
-  <script src="https://unpkg.com/reveal.js/plugin/notes/notes.js"></script>
+  <script src="https://unpkg.com/reveal.js@^4//plugin/notes/notes.js"></script>
-  <script src="https://unpkg.com/reveal.js/plugin/search/search.js"></script>
+  <script src="https://unpkg.com/reveal.js@^4//plugin/search/search.js"></script>
-  <script src="https://unpkg.com/reveal.js/plugin/zoom/zoom.js"></script>
+  <script src="https://unpkg.com/reveal.js@^4//plugin/zoom/zoom.js"></script>
  <script>
--- a/src/header.html
+++ b/src/header.html
@ -1,20 +1,17 @@
 <link rel="preconnect" href="https://fonts.googleapis.com">
 <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
 <link href="https://fonts.googleapis.com/css2?family=JetBrains+Mono:ital,wght@0,100..800;1,100..800&display=swap" rel="stylesheet">
 <style>
 body {
-  font-family: "JetBrains Mono", monospace;
+ font-family:  ui-sans-serif;
 }
 .reveal h1,  .reveal h2,  .reveal h3,  .reveal h4,  .reveal h5,  .reveal h6 
 {
-  font-family: "JetBrains Mono", monospace;
+  font-family:"TruenoSemiBold", "ui-sans-serif";
 }
@font-face{
-  font-family: "JetBrains Mono", monospace;
+  font-family:"TruenoSemiBold";
  src:local("TruenoSemiBold"),
  url("./fonts/TruenoSemiBold.woff2") format("woff2");
  font-weight: 600;
 }
 .black h2 {
  background-color: #020210;
 }
@ -25,6 +22,7 @@ body {
 .reveal .slides p {
  margin: 2rem 0;
  text-align:left;
 }
 .reveal .slides blockquote > p {
--- a/src/index.md
+++ b/src/index.md
@ -1,316 +1,130 @@
 ---
-title: Konduit.channel
+title: Cardano Lightning
-subtitle: "[A bunch of ideas in 15mins]"
+subtitle: Permissionless, near instant, highly scalable 
-mainfont: monospace
+mainfont: TruenoSemiBold
 background-image: ./assets/background.svg
 background-opacity: "0.35"
 title-slide-attributes:
    data-background-image: ./assets/logo.png
    data-background-size: contain
    data-background-opacity: "0.3"
 background-image: ./assets/background.svg
 background-opacity: "0.35"
 toc-title: "toc"
 toc-depth: 1
 ---
-## What is ... 
+## Problem
-### Konduit?
+### Payments
-> A Cardano to Bitcoin Lighting Pipe
+- A fundamental part of all commerce: payment. 
-<!-- 
+### Who?
    The first question is then "what is Bitcoin Lightning"
 --> 
-### Bitcoin Lightning? 
+There are three parties involved in a payment
-... a payment protocol built on bitcoin intended to enable fast transactions among participating nodes 
+- Consumer (ie payer)
-and has been proposed as a solution to the bitcoin scalability problem.
+- Provider (ie payee)
 - Facilitator
-<!--
+All of us are consumers, some are providers, a few are facilitators.
    A slight abbreviation of the wiki entry 
-    A slightly trucated opening lines from the wikipedia page. 
+### What users want
    Whoever provided or endorsed this version clearly thinks this point is moot.
 --> 
-### The problem?
+> Users want secure, fast, low cost transactions
-::: {style="display:flex;flex-direction:row;justify-content: space-around; align-items: center;"}
+However participants have different priorities, _eg_
-![](./assets/does-it-scale.jpg)
+- Consumers want ease-of-use
 - Providers want fast confirmation 
 - Facilitators need to handle at scale
- Scalability
+### Existing systems (1/2)
 - Finality
 - Tx fees
-:::
+- Cash: Permissionless, instant, scalable-ish (lots of people can use it at the same time, but only to pay people near them), 
 questionable security (fraud happens).
 - Bank transfer: Permissioned, some instant others very slow, scalable.
 - Contactless/ Card: Permissioned, near instant, scalable
-<!-- 
+### ... (2/2)
    The classic complaints about (real) L1s
-    You cannot walk into a cafe, say, and purchase a coffee on the L1.
+- Decentralised Ledger \*: permissionless, maybe fast or scalable but generally not both.
    Ok its probably fine (we have no traffic, long rollbacks don't happen. wink emoji).
    But it shouldn't make sense: We cannot have all the nodes handling everyone's morning coffee purchase. 
    It does not scale.
-    On finality, we arn't really competing with web2.
+<span style="font-size: small">
-    Payment providers can retroactively deny payments (no source).
+\* There are many different designs of decentralised ledger,
 each with different choices and trade-offs. 
 Some permissioned, some more decentralised than others, some faster, _etc_.
 </span>
-    We, Cardano, have the same problem. 
+### Market size
    One route to remedy: don't reinvent the wheel, piggy back on their wheel. 
 --> 
 ### The ask
-Can we go from Cardano to BLN?
+- Contactless transactions will reach $11 trillion by 2027 <span style="font-size: small"> source : Juniper Research </span>
-<!-- 
+- Market Cap for crypto : > $3 trillion <span style="font-size: small"> source : coinmarketcap.com (Dec 2024) </span>
    Lightning exists. It has some level of adoption. 
    Some cafes accept lighting payments. 
    Could we open this up to ada holders?! 
    Not for the merchants necessarily, but for the consumers.
 --> 
-## Lightning / BLN
+### Intersection
-<!-- 
+> Can we have contactless like experience but permissionless.
    A lightning round on Lightning network
 -->
-### Overview
+### Problem statement 
- A network of two party channels
+We want a payment system that is:
 - L1: Each channel is "underwritten" by locked funds
 - L2: exchanging messages alters how and who can claim these funds
-<!-- 
+1. Permissionless and secure
-    Lightning is a network of two party channels.
+2. Near instant 
-    Each channel corresponds to a utxo holding the funds on the L1 that underwrite L2 messages. 
+3. Highly scalable
    For example you could have a channel with the coffee shop,
    and for each morning coffee is paid for via an L2 message.
-    Immediate questions:
+### Bitcoin Lightning Network?
-    - Do i need a channel with everyone I want to pay? If so whats the point?
+In a lightning network:
    - How is this a network?
-    An asside: This is a super interesting setup. 
+- The network is fundamentally a set of channels, not a shared ledger. 
-    Subscription based services are "handwave" north of a trillion dollars and growing.
+- There is no need to reach consensus, or globally broadcasting state. 
--> 
+- Payments are routed across channels by participants.
 - Speed of payment isn't a global property, but a more local one. 
-### Hops 
+BLN does this and is the closest to meeting our aims. 
- 2 channels: Alice <-> Bob; Bob <-> Charlie 
+### Problems with BLN
 - Alice ~> Charlie ? 
 - Alice ~> Bob ~> Charlie.
 - Problem: Naive hops require trust
-<!--
+However it has some issues:
    How to make a set of channels a network. 
-    Shoe horning in another idea: 
+- Large technical and resource overhead to use. Every user must run a node. 
 - Difficult to efficiently manage capital. 
 Liquidity is required to enable payments to be routed across a network. 
 Moving capital between channels requires multiple transactions.
-    The topology of our networks should reflect their use case. 
+## Solution
    The L1 makes it as easy for anyone to pay anyone: 
    a very flexible basis, but this is basically nobodies use case. 
    I'm far more likely to pay somone i've already paid, than someone at random. 
 -->
-### HTLCs 
+### Cardano Lightning
- Trustless hops
+### Design 
 - Hashed TimeLocked Contract 
 - Parameterized by `(timeout, lock, payer, payee)`
 - Two spend pathways:
    - Ok: Signed by `payee`; Before `timeout`; Has `secret`
    - Ko: Signed by `payer`; After `timeout`
 - Note: `hash(secret) == lock`
-<!--
+- A perturbation on BLN: its a Lightning Network
-    Enter HTLCs 
+- Focused on addressing the key technical blockers 
 to it being used as a day-to-day payment system. 
-    This is a basic implementation of an HTLC. 
+### Tailored Nodes
-    In practice we want to reuse the same locked funds multiple times, 
+CL recognises a diversity users have a diversity of needs.
    and for values, timeouts, and locks that are not apriori known.
    But ultimately, its some version of this. 
-    A warning: the term HTLC is used to mean the "contract", the output at the contract, the would be output in tx not submitted, 
+- For consumers we have a lightweight node, minimal resources, and runs on their phone. 
-    and the general concept illustrated
+- Some providers might be happy running their own servers, others wont. 
-->
+There's a flexible CL node + SDK to suit a full spectrum of usecases.
-### Routes
+### Leveraging Cardano
- C ~> A : Invoice including lock.
+- Cardano's more powerful scripting language allows
- A ~> B : HTLC with timeout `T` and lock 
+us to achieve more with less. In particular we can optimize capital allocation for nodes.
 - B ~> C : HTLC with timeout `T - delta` and lock 
 - C ~> B : Secret
 - B ~> C : Commitment to pay (no htlc)
 - B ~> A : Secret
 - A ~> B : Commitment to pay (no htlc)
-<!--
+- For the facilitators, we have a node for efficient handling of many channels concurrently. 
-    This is the message flow, at least for the happy path. 
+Those with capital and wanting to put it to use become the facilitators.
-    We need to unpack the unhappy branch on each line.
+They receive income on the service they provide, each payment they facilitate in routing. 
    "What if the message never arrives" (sent or otherwise).
-    Now we know how lightning works. 
+## Team
    We have avoided saying what these commitments look like. 
    Implementation detail.
    We haven't said anything about finding viable routes.
    (Essentially magic.)
-    But we've said very little about bitcoin. 
+###
    Great so we should just implement lightning on Cardano! 
 -->
-## Cardano Lightning
+- @waalge 
-
+- @paluh 
-### Pitch 
+- @nhenin 
 - Do Lightning but on Cardano
 . . .
 - And better
 <!--
    Why? Its a fun project.
    Lightning is too complicated.
    Its hard to reason about, its hard to implement, its hard to adapt. 
    Lightning has two key problems: 
        - All nodes are full nodes (anyone can route, and has to run a full node)
        - Fund drift
    Both are manifestations that lightning topology does not reflect the problematic. 
    We have good reason to think we can do much better on these fronts using Cardano.
    Recall that the original ask is to get from Cardano to BLN (not back again)
    Every feature comes at some cost.
    Full lightning is not cheap (it also doesn't yet exist). 
    The CL project is happening and is the reason I'm here, but this was not the ask.
    One more digression: Why was invited to build CL?
 -->
 ## Subbit.xyz
 ### Trustless<sup>\*</sup> subscriptions
 - Alice wants to subscribe to Bob's service
 - Alice locks funds on the L1; Bob sees
 - Each request Alice includes an "IOU"; Bob verifies and responds
 - At Bob's leisure, he claims (`subs`) funds owed
 An embarrassingly simple L2 
 <!--
    At any point either party can stop participating.
    Moreover, they are able to claim the funds demonstrably theirs 
    (perhaps after a waiting period). 
    The astricks is to indicate that Bob may cheat Alice in his response. 
    Alice ought to stop using the service as soon as this is the case. 
 -->
 ### IOU
 ```cddl
 amount = int
 signature = bytestring .size 64 
 iou = #6.121( [ amount, signature ] )
 ```
 ```cddl
 tag = bytestring
 message = #6.121( [ tag, amount ] ) 
 ```
 <!--
    Each channel has a `tag`. This allows Alice to use her key for multiple channels.
    This is it.
    Bob presents this to the L1 and takes funds owed.
    Note this doesn't close the channel, and the action is ~idempotent. 
    That is, if Bob reused the same IOU he'd not be able to extract any more funds. 
 --> 
 ### Unidirectionality boons
 - Alice's safety is not dependent on chain liveness
 - Bob's sub is unilateral. No contestation.
 ### Overhead?
 - Alice (client) must remember their keys
 - Must be able to produce a signature
 - Maybe some other state (< 100 bytes) or 2 trips.
 ## Konduit
 <!-- 
    Ok. Back on topic: how are we going to meet the ask
 --> 
 ### Subbit + HTLCs
 Not IOUs, but cheques + squashes
 ```cddl
 cheque_body = [index, amount, timeout, lock]
 cheque = [cheque_body, signature]
 excludes = [* index]
 squash_body = [amount, index, excludes] 
 squash = [squash_body, signature]
 ```
 <!-- 
    The role is essentially the same. 
    The signature is of a message that is a mild reworking of the version in subbit.
    On a happy path, a cheque is made, a secret learned and shared, and the cheque is squashed. 
 --> 
 ### Keep the boons
 - Alice still doesn't need chain liveness
 - Bob unilateral subs now have the evidence:
 ```cddl
 unlocked = [cheque_body, signature, secret]
 receipt = [squash, [*unlocked]] 
 ```
 <!-- 
    On the happy path the list of unlockeds will be empty.
    But maybe Alice goes offline before bob learns the secret. 
 --> 
 ### Other deets 
 - Token free design
 - "Batch" txs are first class
 - "Mutual" txs are first class and invoke no futher verification steps 
 (beyond `required_signers`)
 <!-- 
 --> 
 ## Demo ?!
 ### Soon™
 ## Ideas 
 ### ideas inner {style="display:none"}
 - The topology of our networks should reflect their usage
 - Cardano's super power: verify signatures of arbitrary data
 - All dapps should be L2s
 - A dapp devs main role is to keep user's from others
 - You don't need tokens