[Lightning-dev] Proposal: Decentralized Service Provider
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.
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
> 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.
More information about the Lightning-dev