path: root/a6/cb419fd05f08d3a56a239ba9f72b323e5b43a0

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9AEFB273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 17:12:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com
	[209.85.213.176])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D590D11E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 17:12:55 +0000 (UTC)
Received: by igrv9 with SMTP id v9so27597885igr.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 28 Jun 2015 10:12:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=yLtJhlEZec9IE2mJDJDGqokPxf/y6e3dyTClcaTk4J0=;
	b=bZ5o9Xd5GpgYrqgj2/dt2xsbL/etIzjCImGMT5C32RKRyEmPizzIBJ4PU5gZffz4/9
	Ry4v90UpqSbYD2Vibdzr6cSyzt9PiGyspNZ45hAIlsl8c+aBIXAmPQDx/ZxdznH/PVTD
	XoxuYP4eykPc8Zx6Q6cMN08nnS7opmNfBj9Kac3R+0aKQ200dsnwotAGWrWg11M8HzNg
	3fFlZYMdEYX6GT7wAUx7xatNR9xB18Lt7sn1mbLOyOe+QV0p/4Y3jB0qaaIn8XDvyuA+
	oV0zv00nT/FRXAbbDM6340hNtifVHk6+hDH59J62Yz9sqm1TRvVsdec7H0Y+zBFjM3Jd
	4BCQ==
X-Gm-Message-State: ALoCoQk2FhxMolbnVm2GmQ+gGsrQQGTmdd6dD08FDdelLHYwxxWUz9xNRIz0eDmUSmke+vYLGAC1
X-Received: by 10.50.79.230 with SMTP id m6mr10203617igx.46.1435511575291;
	Sun, 28 Jun 2015 10:12:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.149.20 with HTTP; Sun, 28 Jun 2015 10:12:35 -0700 (PDT)
X-Originating-IP: [50.0.37.37]
In-Reply-To: <COL131-DS8E3DCDBD1A0F359206781CDAB0@phx.gbl>
References: <COL402-EAS1148599DFFBB257C33F293ACDAB0@phx.gbl>
	<CALqxMTHbeyyVAO9qXO4wrQo3sCh89gwMRS9BjiN+4iMs-bt5ow@mail.gmail.com>
	<CAOoPuRarNoPwLxVqjJ_g4b6HsWJecB-oCdfEjaknKbUnKdnmEg@mail.gmail.com>
	<CALqxMTGXcbES5Pwz3cWO+PQK5kmf3rZ_i00=b=PBnO678XuF0A@mail.gmail.com>
	<COL131-DS8E3DCDBD1A0F359206781CDAB0@phx.gbl>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Sun, 28 Jun 2015 10:12:35 -0700
Message-ID: <CAOG=w-swydsyzHx7kWKCCWnrDT0kG=c+FTDmwFD3sjbA0i4TpA@mail.gmail.com>
To: "Raystonn ." <raystonn@hotmail.com>
Content-Type: multipart/alternative; boundary=089e01229aaa8447d20519971592
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2015 17:12:56 -0000

--089e01229aaa8447d20519971592
Content-Type: text/plain; charset=UTF-8

Think in terms of participants, not addresses. A participant in the
lightning network has a couple of connections to various hubs, from which
the participant is able to send or receive coin. The user is able to send
coins to anyone connected to the lightning network by means of an atomic
transaction through any path of the network. But the only payment from them
that ever hits the chain is their settlement with the hub.

Imagine there was a TCP/IP data chain and corresponding lightning network.
Everyone connected to the network has an "IP" channel with their ISP.
Through this channel they can send data to anywhere on the network, and a
traceroute shows what hops the data would take. But when settlement
actually occurs all the network sees is the net amount of data that has
gone through each segment -- without any context. There's no record
preserved on-chain of who sent data to whom, just that X bytes went through
the pipe on the way to somewhere unspecified.

So it is with lightning payment networks. You open a channel with a hub and
through that channel send coins to anyone accessible to the network.
Channels only close when a participant needs the funds for non-lightning
reasons, or when hubs need to rebalance. And when they do, observers on the
chain learn nothing more than how much net coin moved across that single
link. They learn nothing about where that coin eventually ended up.

So back to your original question, each channel can be considered to have a
pseudonymous identity, and each new channel given a new identity. Channel
closures can even be coinjoin'd when the other party is cooperating. But
ultimately, lightning usefully solves a problem where participants have
semi-long lived payment endpoints.

On Sun, Jun 28, 2015 at 9:32 AM, Raystonn . <raystonn@hotmail.com> wrote:

> Write coalescing works fine when you have multiple writes headed to the
> same (contiguous) location.  Will lightning be useful when we have more
> unique transactions being sent to different addresses, and not just
> multiple transactions between the same sender and address?  I have doubts.
>
>
> -----Original Message----- From: Adam Back
> Sent: Sunday, June 28, 2015 5:37 AM
> To: Benjamin
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
>
>
> On 28 June 2015 at 12:29, Benjamin <benjamin.l.cordes@gmail.com> wrote:
>
>> I agree that naive scaling will likely lead to bad outcomes. They might
>> have
>> the advantage though, as this would mean not changing Bitcoin.
>>
>
> Sure we can work incrementally and carefully, and this is exactly what
> Bitcoin has been doing, and *must* do for safety and security for the
> last 5 years!
> That doesnt mean that useful serious improvements have not been made.
>
>  Level2 and Lightning is not well defined. If you move money to a third
>> party, even if it is within the constrained of a locked contract, then I
>> don't think that will solve the issues.
>>
>
> I think you misunderstand how lightning works.  Every lightning
> transaction *is* a valid bitcoin transaction that could be posted to
> the Bitcoin network to reclaim funds if a hub went permanently
> offline.  It is just that while the hubs involved remain in service,
> there is no need to do so.  This is why it has been described as a
> (write coalescing) write cache layer for Bitcoin.>
>
> I believe people expect lightning to be peer 2 peer like bitcoin.
>
> Adam
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--089e01229aaa8447d20519971592
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Think in terms of participants, not address=
es. A participant in the lightning network has a couple of connections to v=
arious hubs, from which the participant is able to send or receive coin. Th=
e user is able to send coins to anyone connected to the lightning network b=
y means of an atomic transaction through any path of the network. But the o=
nly payment from them that ever hits the chain is their settlement with the=
 hub.<br><br></div>Imagine there was a TCP/IP data chain and corresponding =
lightning network. Everyone connected to the network has an &quot;IP&quot; =
channel with their ISP. Through this channel they can send data to anywhere=
 on the network, and a traceroute shows what hops the data would take. But =
when settlement actually occurs all the network sees is the net amount of d=
ata that has gone through each segment -- without any context. There&#39;s =
no record preserved on-chain of who sent data to whom, just that X bytes we=
nt through the pipe on the way to somewhere unspecified.<br><br></div>So it=
 is with lightning payment networks. You open a channel with a hub and thro=
ugh that channel send coins to anyone accessible to the network. Channels o=
nly close when a participant needs the funds for non-lightning reasons, or =
when hubs need to rebalance. And when they do, observers on the chain learn=
 nothing more than how much net coin moved across that single link. They le=
arn nothing about where that coin eventually ended up.<br><br></div>So back=
 to your original question, each channel can be considered to have a pseudo=
nymous identity, and each new channel given a new identity. Channel closure=
s can even be coinjoin&#39;d when the other party is cooperating. But ultim=
ately, lightning usefully solves a problem where participants have semi-lon=
g lived payment endpoints.<br></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Sun, Jun 28, 2015 at 9:32 AM, Raystonn . <span dir=3D=
"ltr">&lt;<a href=3D"mailto:raystonn@hotmail.com" target=3D"_blank">rayston=
n@hotmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Write=
 coalescing works fine when you have multiple writes headed to the same (co=
ntiguous) location.=C2=A0 Will lightning be useful when we have more unique=
 transactions being sent to different addresses, and not just multiple tran=
sactions between the same sender and address?=C2=A0 I have doubts.<br>
<br>
<br>
-----Original Message----- From: Adam Back<br>
Sent: Sunday, June 28, 2015 5:37 AM<br>
To: Benjamin<br>
Cc: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit<di=
v class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On 28 June 2015 at 12:29, Benjamin &lt;<a href=3D"mailto:benjamin.l.cordes@=
gmail.com" target=3D"_blank">benjamin.l.cordes@gmail.com</a>&gt; wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I agree that naive scaling will likely lead to bad outcomes. They might hav=
e<br>
the advantage though, as this would mean not changing Bitcoin.<br>
</blockquote>
<br>
Sure we can work incrementally and carefully, and this is exactly what<br>
Bitcoin has been doing, and *must* do for safety and security for the<br>
last 5 years!<br>
That doesnt mean that useful serious improvements have not been made.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Level2 and Lightning is not well defined. If you move money to a third<br>
party, even if it is within the constrained of a locked contract, then I<br=
>
don&#39;t think that will solve the issues.<br>
</blockquote>
<br>
I think you misunderstand how lightning works.=C2=A0 Every lightning<br>
transaction *is* a valid bitcoin transaction that could be posted to<br>
the Bitcoin network to reclaim funds if a hub went permanently<br>
offline.=C2=A0 It is just that while the hubs involved remain in service,<b=
r>
there is no need to do so.=C2=A0 This is why it has been described as a<br>
(write coalescing) write cache layer for Bitcoin.&gt;<br>
<br>
I believe people expect lightning to be peer 2 peer like bitcoin.<br>
<br>
Adam<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a> <br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>

--089e01229aaa8447d20519971592--