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.delboni...@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to