Good morning Cezary, Once you have had the insight, that a "blockchain" is really a subclass of "cryptocurrency system", and that a "Lightning Network payment channel" is really a subclass of the same "cryptocurrency system" (except the constructor for CLightningPaymentChannel itself has a CCryptocurrencySystem as argument, wheres a constructor for CBlockchain has no arguments in its constructor, i.e. is not dependent on the existence of another cryptocurrency system), then you realize that it is immaterial, theoretically, whether an LN payment channel is built on Bitcoin, on another blockchain, or on another LN payment channel.
In particular, see Fulgurite: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001721.html The key insight here is that with Decker-Wattenhofer and Decker-Russell-Osuntokun, we can have a multiparticipant "payment channel", i.e. a CCryptocurrencySystem (whose constructor requires an existing CCryptocurrencySystem). And that multiparticipant payment channel can itself be used to instantiate other payment channels (which are themselves subclasses of CCryptocurrencySystem). The hard part is the dreary spec-work of defining what messages are needed, how to make the system extensible, etc. I believe Fulgurite is that effort, which also wants to somehow be compatible with the existing LN spec. In short, yes, it's theoretically possible to build LN on any cryptocurrency system, whether Bitcoin mainchain, Ethereum, another cryptocurrency system that is not a blockchain, and so on. The only minimum requirement is that the cryptocurrency system need to support only a particular small minimum set of functionality. For Poon-Dryja and Decker-Wattenhofer channels it requires only multisignatures, hashlocks, and (absolute and relative) timelocks. For Decker-Russel-Osuntokun it requires multisignatures, hashlocks, timelocks, and `SIGHASH_NOINPUT`. (note that Poon-Dryja is restricted to two participants, while the Decker-* variants are multiparticipant but either require longer timelocks on one-sided close (Decker-Wattenhofer) or the new untested `SIGHASH_NOINPUT` (Decker-Russell-Osuntokun)) Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 27, 2019 5:47 PM, Cezary Dziemian <cezary.dziem...@gmail.com> wrote: > Hi group, > > Do you think it would be possible to run LN on top of plasma chain instead of > main chain? That would make plasma layer-2 solution and LN layer-3 solution. > > In long-term future it would make a lot of sense to have "full node" > containing main chain, at least one plasma chain and LN. We can imagine then, > that we would install "full node" on mobile phone and no need to use SPV or > neutrino. > > Best, > CD _______________________________________________ Lightning-dev mailing list Lightningfirstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev