ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-05 📝 Original message: Hi Trey, This document is ...
📅 Original date posted:2018-12-05
📝 Original message:
Hi Trey,
This document is a description of how I view individual channels on Lightning currently.
The document is valuable as it provide a viewpoint of how Lightning works at each channel.
Burchert-Decker-Wattenhofer channel factories are essentially multiparty (> 2 participants) "channels" ("offchain updateable cryptocurrency systems") with multiple "child" 2-party channels.
In general though having multiple channels between the same 2 participants is not as valuable (which is why Burchert-Decker-Wattenhofer only has two levels in the hierarchy, and why the parent level is multiparty while the child level is 2-party).
Punishment mechanisms are simply part of the update protocol (they are a witness that older states have been superseded).
We can abstract away the update protocol (Decker-Wattenhofer, Poon-Dryja, Decker-Russell-Osuntokun) from the description in the document.
Of note is that the existing update protocols can carry almost any Bitcoin-enforceable contract, including the same contracts used to enforce them.
This is what allows update protocols to "nest" as in Burchert-Decker-Wattenhofer (or your concept of "parent" and "child" channels).
There are some important details like the fact that Decker-Wattenhofer and Decker-Russell-Osuntokun impose an extra CSV on their transported contracts, and most contracts cannot be transported across systems (HTLCs can but with longer timelocks for each step).
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, December 6, 2018 3:12 AM, Trey Del Bonis <j.delbonis.3 at gmail.com> wrote:
> Hello all,
>
> I've been doing some thinking lately about some of the Lightning extension
> proposals like splicing and have been trying and try to generalize it into
> something that makes Lightning a lot more flexible and fault-tolerant overall.
>
> So I wrote up a document describing what I call "Fulgurite", after the term for
> fossilized lightning.
>
> Link: https://tr3y.io/media/docs/fulgurite.pdf (also attached)
> SHA1: d25371836a56630571182a65684df19027c3b9af
>
> It makes tracking channel state into building on a graph with moving forward in
> time, and merges the ideas of user balances and HTLCs into different types of
> "channel partitions" which are also used for other things I talk about in the
> doc.
>
> Ideally, it can make splicing and subchannels simpler. It also makes it pretty
> trivial to do discreet log contracts in channels vs on-chain, which is good for
> anonymity.
>
> I've been working on a toy implementation of the things in Fulgurite here, this
> isn't usable yet but there's the core parts: https://gitlab.com/delbonis/roz
>
> - Trey Del Bonis
>
> PS. If you were at the Chaincode Residency in October, you might know me as the
> guy that did Conway's Place! (= Conway's Game of Life + satoshis.place)
>
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
Hi Trey,
This document is a description of how I view individual channels on Lightning currently.
The document is valuable as it provide a viewpoint of how Lightning works at each channel.
Burchert-Decker-Wattenhofer channel factories are essentially multiparty (> 2 participants) "channels" ("offchain updateable cryptocurrency systems") with multiple "child" 2-party channels.
In general though having multiple channels between the same 2 participants is not as valuable (which is why Burchert-Decker-Wattenhofer only has two levels in the hierarchy, and why the parent level is multiparty while the child level is 2-party).
Punishment mechanisms are simply part of the update protocol (they are a witness that older states have been superseded).
We can abstract away the update protocol (Decker-Wattenhofer, Poon-Dryja, Decker-Russell-Osuntokun) from the description in the document.
Of note is that the existing update protocols can carry almost any Bitcoin-enforceable contract, including the same contracts used to enforce them.
This is what allows update protocols to "nest" as in Burchert-Decker-Wattenhofer (or your concept of "parent" and "child" channels).
There are some important details like the fact that Decker-Wattenhofer and Decker-Russell-Osuntokun impose an extra CSV on their transported contracts, and most contracts cannot be transported across systems (HTLCs can but with longer timelocks for each step).
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, December 6, 2018 3:12 AM, Trey Del Bonis <j.delbonis.3 at gmail.com> wrote:
> Hello all,
>
> I've been doing some thinking lately about some of the Lightning extension
> proposals like splicing and have been trying and try to generalize it into
> something that makes Lightning a lot more flexible and fault-tolerant overall.
>
> So I wrote up a document describing what I call "Fulgurite", after the term for
> fossilized lightning.
>
> Link: https://tr3y.io/media/docs/fulgurite.pdf (also attached)
> SHA1: d25371836a56630571182a65684df19027c3b9af
>
> It makes tracking channel state into building on a graph with moving forward in
> time, and merges the ideas of user balances and HTLCs into different types of
> "channel partitions" which are also used for other things I talk about in the
> doc.
>
> Ideally, it can make splicing and subchannels simpler. It also makes it pretty
> trivial to do discreet log contracts in channels vs on-chain, which is good for
> anonymity.
>
> I've been working on a toy implementation of the things in Fulgurite here, this
> isn't usable yet but there's the core parts: https://gitlab.com/delbonis/roz
>
> - Trey Del Bonis
>
> PS. If you were at the Chaincode Residency in October, you might know me as the
> guy that did Conway's Place! (= Conway's Game of Life + satoshis.place)
>
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev