From light at bitseed.org Fri Mar 11 18:06:43 2016 From: light at bitseed.org (light at bitseed.org) Date: Fri, 11 Mar 2016 10:06:43 -0800 Subject: [Lightning-dev] Lightning-dev Digest, Vol 10, Issue 14 In-Reply-To: References: Message-ID: <77d2aa15180ba4d9f3f661afe874112b@bitseed.org> 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 > 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 > *********************************************