[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.

http://opentransactions.org/wiki/index.php?title=Category:Voting_Pools

This is similar to how Blockstream is securing their Liquid consortium 
sidechain:

https://www.blockstream.com/2015/11/02/liquid-recap-and-faq/

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 
your proposal.

http://interledger.org/

The real magic, it seems, is in the pathfinding between hub nodes and 
endpoints.

JL

On 2016-03-11 04:00, lightning-dev-request at lists.linuxfoundation.org 
wrote:
> 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 
> 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.
> 
> 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.
> 
> 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.
> 
> Thanks for your attention!
> 
> Sam
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> 
> 
> End of Lightning-dev Digest, Vol 10, Issue 14
> *********************************************



More information about the Lightning-dev mailing list