---
title: Konduit.channel
subtitle: "[A bunch of ideas in 15mins]"
mainfont: monospace
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 ... 

### Konduit?

> A Cardano to Bitcoin Lighting Pipe

<!-- 
    The first question is then "what is Bitcoin Lightning"
--> 

### Bitcoin Lightning? 

... 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.

<!--
    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.
--> 

### The problem?

::: {style="display:flex;flex-direction:row;justify-content: space-around; align-items: center;"}

![](./assets/does-it-scale.jpg)

- Scalability
- Finality
- Tx fees

:::

<!-- 
    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. 
--> 

### The ask

Can we go from Cardano to BLN?

<!-- 
    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

<!-- 
    A lightning round on Lightning network
-->

### Overview

- A network of two party channels
- L1: Each channel is "underwritten" by locked funds
- L2: exchanging messages alters how and who can claim these funds

<!-- 
    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.
--> 

### Hops 

- 2 channels: Alice <-> Bob; Bob <-> Charlie 
- Alice ~> Charlie ? 
- Alice ~> Bob ~> Charlie.
- Problem: Naive hops require trust

<!--
    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. 
-->

### HTLCs 

- Trustless hops
- 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`

<!--
    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
-->

### Routes

- C ~> A : Invoice including lock.
- A ~> B : HTLC with timeout `T` and lock 
- 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)

<!--
    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! 
-->

## Cardano Lightning

### Pitch 

- 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