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

Reply via email to