From rusty at rustcorp.com.au  Wed Mar 16 02:40:26 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 16 Mar 2016 13:10:26 +1030
Subject: [Lightning-dev] Proposal: Decentralized Service Provider
In-Reply-To: <56E286AD.5060506@kremser-crypto.org>
References: <56E286AD.5060506@kremser-crypto.org>
Message-ID: <87twk79mcl.fsf@rustcorp.com.au>

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.