[Lightning-dev] Lightning-dev Digest, Vol 10, Issue 14
light at bitseed.org
light at bitseed.org
Fri Mar 11 18:06:43 UTC 2016
I like this proposal, Sam! This sounds similar to the "voting pools"
concept described by Justus Ranvier as a way to secure bitcoin that is
deposited into Open Transactions notary servers. This way, as you
pointed out, there can be no single point of failure.
This is similar to how Blockstream is securing their Liquid consortium
I could see a hybrid of Bitcoin multisig voting pools, OT servers, and
Interledger-style contracts (to make payments between servers without
friction) being used to fulfill a similar purpose to that described in
The real magic, it seems, is in the pathfinding between hub nodes and
On 2016-03-11 04:00, lightning-dev-request at lists.linuxfoundation.org
> Message: 1
> Date: Fri, 11 Mar 2016 09:49:49 +0100
> From: Samuel Kremser <sam at kremser-crypto.org>
> To: lightning-dev at lists.linuxfoundation.org
> Subject: [Lightning-dev] Proposal: Decentralized Service Provider
> Message-ID: <56E286AD.5060506 at kremser-crypto.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
> Hi Guys!
> I wanna make a improvement proposal for the Lightning Network and would
> like to hear your thoughts about it.
> 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. 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
> 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.
> DSP's entities communicate with signed messages with their end users
> with each other, so everything is provable. Whenever some entity of a
> is acting malicious the other entities of that DSP can decide to
> 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.
> 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
> more space on the Blockchain than Lightning alone.
> Thanks for your attention!
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> End of Lightning-dev Digest, Vol 10, Issue 14
More information about the Lightning-dev