[Lightning-dev] Lightning-dev Digest, Vol 10, Issue 14

Samuel Kremser sam at kremser-crypto.org
Fri Apr 1 18:37:10 UTC 2016


Hi Jerome!

> A limitation I see is that service providers will need to promote 
> themselves in the open as they unfortunately cannot be anonymous and 
> hide behind TOR for example: if I am a customer, I don't want to pick 
> a consortium of 7 anonymous providers, because they could very well be 
> the same person. 

True.
But beside having globally distributed DSPs each controlled by several 
trusted persons/entities, you could also set up you own DSP with some 
friends.
I imagine some WLAN router-sized device that act as a node of such a DSP.
Now if you decide with some friends to set up your own DSP each one of 
you installs such a device at home and connects it to the internet. 
Together these devices form the DSP-network.
Afterwards you set up your and your families payment devices to connect 
to this DSP, so do your friends.
Since access to this DSP is probably protected with some password this 
DSP is hard to attack.
Also i think this is hard to regulate for a government.

Sam

Am 01.04.2016 um 09:05 schrieb Jérôme Legoupil:
> Hi Sam,
>
> I think this is a good idea. Here are a few thougths I want to throw in.
>
> I see this as a higher level protocol on top of Lightning network 
> (Blockchain is like IP layer, Lightning is like TCP transport layer, 
> ...): offchain wallet providers on top of LN.
>
> Also, having multisig bonded service providers in different 
> juridictions offers a strong protection to these providers themselves 
> and their customers against legal risks.
>
> A limitation I see is that service providers will need to promote 
> themselves in the open as they unfortunately cannot be anonymous and 
> hide behind TOR for example: if I am a customer, I don't want to pick 
> a consortium of 7 anonymous providers, because they could very well be 
> the same person.
>
> These providers would be exposed to DDoS attacks.
>
> 2 customers from the same consortium of providers can transact without 
> even using LN.
>
> The compliance rules these service providers will need to follow is an 
> open question, but I feel pretty optimistic about this.
>
> And I agree this would enable pretty much infinite scalability, 
> because at the end of the day, it is like scaling a dumb database. 
> These providers could also be helpful to reduce and limit the UTXO set.
>
> Cheers,
> Jerome
>
> 2016-03-11 13:00 GMT+01:00 
> <lightning-dev-request at lists.linuxfoundation.org 
> <mailto:lightning-dev-request at lists.linuxfoundation.org>>:
>
>     Send Lightning-dev mailing list submissions to
>     lightning-dev at lists.linuxfoundation.org
>     <mailto:lightning-dev at lists.linuxfoundation.org>
>
>     To subscribe or unsubscribe via the World Wide Web, visit
>     https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>     or, via email, send a message with subject or body 'help' to
>     lightning-dev-request at lists.linuxfoundation.org
>     <mailto:lightning-dev-request at lists.linuxfoundation.org>
>
>     You can reach the person managing the list at
>     lightning-dev-owner at lists.linuxfoundation.org
>     <mailto:lightning-dev-owner at lists.linuxfoundation.org>
>
>     When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of Lightning-dev digest..."
>
>
>     Today's Topics:
>
>        1. Proposal: Decentralized Service Provider (Samuel Kremser)
>
>
>     ----------------------------------------------------------------------
>
>     Message: 1
>     Date: Fri, 11 Mar 2016 09:49:49 +0100
>     From: Samuel Kremser <sam at kremser-crypto.org
>     <mailto:sam at kremser-crypto.org>>
>     To: lightning-dev at lists.linuxfoundation.org
>     <mailto:lightning-dev at lists.linuxfoundation.org>
>     Subject: [Lightning-dev] Proposal: Decentralized Service Provider
>     Message-ID: <56E286AD.5060506 at kremser-crypto.org
>     <mailto: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
>     <mailto:Lightning-dev at lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>     End of Lightning-dev Digest, Vol 10, Issue 14
>     *********************************************
>
>
>
>
> -- 
>
> "If two developers can fork Bitcoin and succeed in redefining what 
> "Bitcoin" is, in the face of widespread technical criticism and 
> through the use of populist tactics, then I will have no choice but to 
> declare Bitcoin a failed project. Bitcoin was meant to be both 
> technically and socially robust. This present situation has been very 
> disappointing to watch unfold."
>
> Satoshi Nakamoto
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160401/047895ef/attachment-0001.html>


More information about the Lightning-dev mailing list