… a payment protocol built on the bitcoin intended to enable fast
+
+
+
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.
-
-
The problem?
+
+
+
The problem?
+
Scalability
Finality
+
Tx fees
+
-
-
Lightning
+
+
The ask
+
Can we go from Cardano to BLN?
+
+
+
+
+
Lightning / BLN
-
Overview
+
+
+
Overview
A network of two party channels
L1: Each channel is “underwritten” by locked funds
-
L2: exchange messages altering how and who can claim these
+
L2: exchanging messages alters how and who can claim these
funds
-
Hops
+
+
+
Hops
2 channels: Alice <-> Bob; Bob <-> Charlie
Alice ~> Charlie ?
@@ -155,56 +228,229 @@ funds
-
HTLCs
+
+
+
HTLCs
-
Hashed TimeLocked Contract (also, utxo and general mechanism).
-
A contract parameterized by (timeout,
-lock, payer, payee ) with two
-spend:
+
Trustless hops
+
Hashed TimeLocked Contract
+
Parameterized by (timeout, lock, payer, payee)
Two spend pathways:
-
Ok:
-
-
Before timeout,
-
Has secret (hash(secret) == lock)
-
Signed by payee
-
-
Ko:
-
-
After timeout,
-
Has payee
-
+
Ok: Signed by payee; Before timeout; Has
+secret
+
Ko: Signed by payer; After timeout
+
Note: hash(secret) == lock
-
Routes
+
+
+
Routes
C ~> A : Invoice including lock.
A ~> B : HTLC with timeout T and lock
-
B ~> C : HTLC with timeout T - d 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)
+
+
+
+
Cardano Lightning
+
+
+
+
Pitch
+
+
Do Lightning but on Cardano
+
+
+
+
And better
+
+
+
+
+
+
+
Subbit.xyz
+
+
+
+
Trustless* 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
“Mutual” txs are first class and invoke no futher verification steps
+(beyond required_signers)
+
+
+
+
+
+
Demo ?!
+
+
+
+
Soon™
+
+
+
+
Ideas
+
+
+
+
ideas inner
+
+
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
+
+
diff --git a/src/index.md b/src/index.md
index 25dbd2d..bd426ea 100644
--- a/src/index.md
+++ b/src/index.md
@@ -1,21 +1,17 @@
---
title: Konduit.channel
-subtitle: (Actually why all\* dapps should be L2s)
-mainfont: Monobrain
+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
---
-## Outline
-
-- What is ...
-- Architecture
-- HTLs
-
## What is ...
### Konduit?
@@ -28,20 +24,27 @@ background-opacity: "0.35"
### Bitcoin Lightning?
-... a payment protocol built on the bitcoin intended to enable fast transactions among participating nodes
+... 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.
-
### The problem?
+::: {style="display:flex;flex-direction:row;justify-content: space-around; align-items: center;"}
+
- Scalability
- Finality
+- Tx fees
+
+:::
-## Lightning
+### The ask
+
+Can we go from Cardano to BLN?
+
+
+
+## Lightning / BLN
### Hops
@@ -94,46 +106,209 @@ and has been proposed as a solution to the bitcoin scalability problem.
### HTLCs
-- Hashed TimeLocked Contract (also, utxo and general mechanism).
-- A contract parameterized by (`timeout`, `lock`, `payer`, `payee` ) with two spend:
-- Two spend pathways:
- - Ok:
- - Before `timeout`,
- - Has `secret` (`hash(secret) == lock`)
- - Signed by `payee`
- - Ko:
- - After `timeout`,
- - Has `payee`
+- 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`
### Routes
- C ~> A : Invoice including lock.
- A ~> B : HTLC with timeout `T` and lock
-- B ~> C : HTLC with timeout `T - d` 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)
+
+## Cardano Lightning
+
+### Pitch
+
+- Do Lightning but on Cardano
+
+. . .
+
+- And better
+
+
+
+## Subbit.xyz
+
+### Trustless\* 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
+
+
+
+### IOU
+
+```cddl
+amount = int
+signature = bytestring .size 64
+iou = #6.121( [ amount, signature ] )
+```
+
+```cddl
+tag = bytestring
+message = #6.121( [ tag, amount ] )
+```
+
+
+
+### 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
+
+
+
+### 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]
+```
+
+
+
+### 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]]
+```
+
+
+
+### 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
