[Lightning-dev] Proposal: Decentralized Service Provider

Rusty Russell rusty at rustcorp.com.au
Wed Mar 16 02:40:26 UTC 2016


Samuel Kremser <sam at kremser-crypto.org> writes:
> Hi Guys!
>
> I wanna make a improvement proposal for the Lightning Network and would 
> like to hear your thoughts about it.

Hi Sam!

        Welcome to the list!

> I am calling it: Decentralized Service Provider (DSP).
>
> A Decentralized Service Provider (DSP) could grant end users access to 
> the Ligthning Network, so they wouldn't have to validate
> the Blockchain or care about closing times of channels.

It's an interesting idea; Lightning As A Service :)

> Also end users 
> would enjoy the benefit of propably much larger
> (filled with more Bitcoins) channels which allows them to send and 
> receive more money, since all users of one DSP would share their channel(s).
>
> Each DSP consists of several entities (propbly also geographically 
> distributed).
> These entities manage the DSP's tasks in a collaborative way.
> These Tasks are:
> 1. Managing Bitcoin deposits and withdrawals
> 2. Managing the Lightning Network Channel(s)
> 3. Managing communication with end users and the Lightning Network
>
> Deposit addresses for the DSP are multi-sig addresses, so that a 
> majority of a DSP's entities is required to sign withdrawals.
> Also the Lightning Network channels are managed in this multi-sig 
> style   .....erm.....  yes i am aware that Lightning Network channels
> are multig-sig anyway, what i wanted to say is: a update to the channel 
> reqiures now a majority of the DSP's entities to singn AND
> the other side of that channel to sign. In case both sides of the 
> Lighting Network channel are DSPs the majority of both DSP's entities 
> need to sign.
>
> Due to this multi-sig construction a single entity of a DSP couldn't 
> steal the end users Bitcoins. It would actually reqire the majority of 
> entities of
> one DSP to collaborate to steal the end users money.

This is better than the current web-wallet model where only one party is
required to steal everything :)

> DSP's entities communicate with signed messages with their end users and 
> with each other, so everything is provable. Whenever some entity of a DSP
> is acting malicious the other entities of that DSP can decide to exclude 
> this entity from this DSP by transferring control of the managed 
> Bitcoins and
> channels to some new multi-sig address(es)/channel(s) that doesn't 
> require the malicous acting entity's signature.
> This could also be done if one entity isn't reliable available.

It's actually tricky to design this system to be robust.  But I look
forward to seeing someone try!

> Another advantage of DSP's would be that fewer channels are reqired, 
> since not every end user needs his own channel. Thus DSPs could save even
> more space on the Blockchain than Lightning alone.

It might shrink the UTXO set, but you still need to transfer bitcoins
in of course.

Cheers,
Rusty.


More information about the Lightning-dev mailing list