<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Jerome!<br>
<br>
<blockquote type="cite">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. </blockquote>
<br>
True.<br>
But beside having globally distributed DSPs each controlled by
several trusted persons/entities, you could also set up you own DSP
with some friends.<br>
I imagine some WLAN router-sized device that act as a node of such a
DSP.<br>
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.<br>
Afterwards you set up your and your families payment devices to
connect to this DSP, so do your friends.<br>
Since access to this DSP is probably protected with some password
this DSP is hard to attack.<br>
Also i think this is hard to regulate for a government.<br>
<br>
Sam<br>
<br>
<div class="moz-cite-prefix">Am 01.04.2016 um 09:05 schrieb Jérôme
Legoupil:<br>
</div>
<blockquote
cite="mid:CAFnMCfcv4+h0PdXtH9-aR7TkvNfFnUNduSzeS4be6Xok+6-vkQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Hi Sam,<br>
<br>
</div>
I think this is a good idea. Here are a few thougths I
want to throw in.<br>
<br>
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.<br>
<br>
Also, having multisig bonded service providers in
different juridictions offers a strong protection to these
providers themselves and their customers against legal
risks. <br>
</div>
<div><br>
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. <br>
<br>
These providers would be exposed to DDoS attacks.<br>
<br>
</div>
<div>2 customers from the same consortium of providers can
transact without even using LN.<br>
</div>
<div><br>
The compliance rules these service providers will need to
follow is an open question, but I feel pretty optimistic
about this.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<br>
</div>
Cheers,<br>
</div>
Jerome<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-03-11 13:00 GMT+01:00 <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:lightning-dev-request@lists.linuxfoundation.org"
target="_blank">lightning-dev-request@lists.linuxfoundation.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Send
Lightning-dev mailing list submissions to<br>
<a moz-do-not-send="true"
href="mailto:lightning-dev@lists.linuxfoundation.org">lightning-dev@lists.linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"
rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a moz-do-not-send="true"
href="mailto:lightning-dev-request@lists.linuxfoundation.org">lightning-dev-request@lists.linuxfoundation.org</a><br>
<br>
You can reach the person managing the list at<br>
<a moz-do-not-send="true"
href="mailto:lightning-dev-owner@lists.linuxfoundation.org">lightning-dev-owner@lists.linuxfoundation.org</a><br>
<br>
When replying, please edit your Subject line so it is more
specific<br>
than "Re: Contents of Lightning-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Proposal: Decentralized Service Provider (Samuel
Kremser)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 11 Mar 2016 09:49:49 +0100<br>
From: Samuel Kremser <<a moz-do-not-send="true"
href="mailto:sam@kremser-crypto.org">sam@kremser-crypto.org</a>><br>
To: <a moz-do-not-send="true"
href="mailto:lightning-dev@lists.linuxfoundation.org">lightning-dev@lists.linuxfoundation.org</a><br>
Subject: [Lightning-dev] Proposal: Decentralized Service
Provider<br>
Message-ID: <<a moz-do-not-send="true"
href="mailto:56E286AD.5060506@kremser-crypto.org">56E286AD.5060506@kremser-crypto.org</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hi Guys!<br>
<br>
I wanna make a improvement proposal for the Lightning
Network and would<br>
like to hear your thoughts about it.<br>
I am calling it: Decentralized Service Provider (DSP).<br>
<br>
A Decentralized Service Provider (DSP) could grant end users
access to<br>
the Ligthning Network, so they wouldn't have to validate<br>
the Blockchain or care about closing times of channels. Also
end users<br>
would enjoy the benefit of propably much larger<br>
(filled with more Bitcoins) channels which allows them to
send and<br>
receive more money, since all users of one DSP would share
their channel(s).<br>
<br>
Each DSP consists of several entities (propbly also
geographically<br>
distributed).<br>
These entities manage the DSP's tasks in a collaborative
way.<br>
These Tasks are:<br>
1. Managing Bitcoin deposits and withdrawals<br>
2. Managing the Lightning Network Channel(s)<br>
3. Managing communication with end users and the Lightning
Network<br>
<br>
Deposit addresses for the DSP are multi-sig addresses, so
that a<br>
majority of a DSP's entities is required to sign
withdrawals.<br>
Also the Lightning Network channels are managed in this
multi-sig<br>
style .....erm..... yes i am aware that Lightning Network
channels<br>
are multig-sig anyway, what i wanted to say is: a update to
the channel<br>
reqiures now a majority of the DSP's entities to singn AND<br>
the other side of that channel to sign. In case both sides
of the<br>
Lighting Network channel are DSPs the majority of both DSP's
entities<br>
need to sign.<br>
<br>
Due to this multi-sig construction a single entity of a DSP
couldn't<br>
steal the end users Bitcoins. It would actually reqire the
majority of<br>
entities of<br>
one DSP to collaborate to steal the end users money.<br>
<br>
DSP's entities communicate with signed messages with their
end users and<br>
with each other, so everything is provable. Whenever some
entity of a DSP<br>
is acting malicious the other entities of that DSP can
decide to exclude<br>
this entity from this DSP by transferring control of the
managed<br>
Bitcoins and<br>
channels to some new multi-sig address(es)/channel(s) that
doesn't<br>
require the malicous acting entity's signature.<br>
This could also be done if one entity isn't reliable
available.<br>
<br>
Another advantage of DSP's would be that fewer channels are
reqired,<br>
since not every end user needs his own channel. Thus DSPs
could save even<br>
more space on the Blockchain than Lightning alone.<br>
<br>
Thanks for your attention!<br>
<br>
Sam<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Lightning-dev@lists.linuxfoundation.org">Lightning-dev@lists.linuxfoundation.org</a><br>
<a moz-do-not-send="true"
href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"
rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
<br>
<br>
End of Lightning-dev Digest, Vol 10, Issue 14<br>
*********************************************<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<p><span style="color:rgb(102,102,102)">"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."</span><span
style="color:rgb(102,102,102)"></span><span
style="color:rgb(102,102,102)"> <br>
</span></p>
<p><span style="color:rgb(102,102,102)">Satoshi Nakamoto</span><span
style="color:rgb(102,102,102)"></span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>