diff options
| author | Benjamin <benjamin.l.cordes@gmail.com> | 2015-06-28 19:18:03 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-28 17:18:05 +0000 |
| commit | 5e98db60ccb42843ec7e33bab13a8e2d797433f2 (patch) | |
| tree | 057fc6249b5891502a8d859d78053a998e8f9f42 | |
| parent | 9c0f417740afd52a43490f6507db7bcc46448421 (diff) | |
| download | pi-bitcoindev-5e98db60ccb42843ec7e33bab13a8e2d797433f2.tar.gz pi-bitcoindev-5e98db60ccb42843ec7e33bab13a8e2d797433f2.zip | |
Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
| -rw-r--r-- | c0/16fd081934d5b889a92995dad4f821cbdb081d | 288 |
1 files changed, 288 insertions, 0 deletions
diff --git a/c0/16fd081934d5b889a92995dad4f821cbdb081d b/c0/16fd081934d5b889a92995dad4f821cbdb081d new file mode 100644 index 000000000..26360bfa7 --- /dev/null +++ b/c0/16fd081934d5b889a92995dad4f821cbdb081d @@ -0,0 +1,288 @@ +Return-Path: <benjamin.l.cordes@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id AA6F8273 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 28 Jun 2015 17:18:05 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com + [209.85.218.52]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 95A83D5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 28 Jun 2015 17:18:04 +0000 (UTC) +Received: by oigx81 with SMTP id x81so104335336oig.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 28 Jun 2015 10:18:04 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type; + bh=Ce3ElcZdHOU8HudricsBkqFXabCKxP9+7YnZZv7QqlE=; + b=G9nk1ejjyyybKtpM1fv9A2ocMgS3/mnAhIwBrfmCbgBdpNZ4mpPmYI9bk/8scKOUV6 + AzDlrsYn+DmwPraQQmf4ibpD7dT50RikqOg9zR5qusuB91FE5YYsfowGdhb7cubuaX1Y + LUBqIsgKtW1ir3IFOZtwtWd2Pv2djGQmRUverBF8BRV+Bpj8/tIDZIoFGGDhEOQOvEcs + x87O6os6l/GfSfgY2BL+2gNwJHCSw2AbEY7AnJabLb0LqBAHKZWy2JVw5jL+299yo7Kf + d08PMk3OhysgbX3LVTd2p5OiNrT70iFqHJsji/FIkOp2Pb//SwG22RrWLstGLAVOaXv9 + 27MA== +MIME-Version: 1.0 +X-Received: by 10.60.37.166 with SMTP id z6mr10240199oej.63.1435511884051; + Sun, 28 Jun 2015 10:18:04 -0700 (PDT) +Received: by 10.202.87.197 with HTTP; Sun, 28 Jun 2015 10:18:03 -0700 (PDT) +In-Reply-To: <CAOG=w-swydsyzHx7kWKCCWnrDT0kG=c+FTDmwFD3sjbA0i4TpA@mail.gmail.com> +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> + <CAOG=w-swydsyzHx7kWKCCWnrDT0kG=c+FTDmwFD3sjbA0i4TpA@mail.gmail.com> +Date: Sun, 28 Jun 2015 19:18:03 +0200 +Message-ID: <CAOoPuRaR_A3ani3d_KVjc4oTfmLYbP52rLsqBEQMZ4gajqoV8A@mail.gmail.com> +From: Benjamin <benjamin.l.cordes@gmail.com> +To: Mark Friedenbach <mark@friedenbach.org> +Content-Type: multipart/alternative; boundary=089e013c6856eb7b49051997276e +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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:18:05 -0000 + +--089e013c6856eb7b49051997276e +Content-Type: text/plain; charset=UTF-8 + +"You open a channel with a hub and through that channel send coins to +anyone accessible to the network." + +Define hub *precisely* and you will find there are +some significant problems here. +a) does everyone know each other in the network? In Bitcoin transacting +parties exchange keys out of band. How do I know that Alice is owner of a +pubkey? I don't, and if don't know Alice I'm out of luck and can't transact +with here (or trust another PKI). +b) hubs need incentives. There are not going to put up collateral just for +nothing. +c) how is complexity reduced? I would speculate that most transactions are +one-time transactions in the time frame of days. + +LT is a very interesting idea, but far from actual implementation. + +On Sun, Jun 28, 2015 at 7:12 PM, Mark Friedenbach <mark@friedenbach.org> +wrote: + +> 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 +>> +> +> + +--089e013c6856eb7b49051997276e +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">"<span style=3D"font-size:12.8000001907349px">You ope= +n a channel with a hub and through that channel send coins to anyone access= +ible to the network."</span><div><span style=3D"font-size:12.800000190= +7349px"><br></span></div><div><span style=3D"font-size:12.8000001907349px">= +Define hub <i>precisely</i> and you will find there are some=C2=A0significa= +nt=C2=A0problems here.=C2=A0</span></div><div><span style=3D"font-size:12.8= +000001907349px">a) does everyone know each other in the network? In Bitcoin= + transacting parties exchange keys out of band. How do I know that Alice is= + owner of a pubkey? I don't, and if don't know Alice I'm out of= + luck and can't transact with here (or trust another PKI).=C2=A0</span>= +</div><div><span style=3D"font-size:12.8000001907349px">b) hubs need incent= +ives. There are not going to put up collateral just for nothing.=C2=A0</spa= +n></div><div><span style=3D"font-size:12.8000001907349px">c) how is complex= +ity reduced? I would speculate that most transactions are one-time transact= +ions in the time frame of days.</span></div><div><span style=3D"font-size:1= +2.8000001907349px"><br></span></div><div><span style=3D"font-size:12.800000= +1907349px">LT is a very interesting idea, but far from actual implementatio= +n.</span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= +te">On Sun, Jun 28, 2015 at 7:12 PM, Mark Friedenbach <span dir=3D"ltr"><= +;<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach= +.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= +rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt= +r"><div><div><div>Think in terms of participants, not addresses. A particip= +ant in the lightning network has a couple of connections to various hubs, f= +rom 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 fr= +om 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 netw= +ork. Everyone connected to the network has an "IP" channel with t= +heir ISP. Through this channel they can send data to anywhere on the networ= +k, and a traceroute shows what hops the data would take. But when settlemen= +t actually occurs all the network sees is the net amount of data that has g= +one through each segment -- without any context. There's no record pres= +erved on-chain of who sent data to whom, just that X bytes went through the= + pipe on the way to somewhere unspecified.<br><br></div>So it is with light= +ning payment networks. You open a channel with a hub and through that chann= +el 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 ab= +out where that coin eventually ended up.<br><br></div>So back to your origi= +nal question, each channel can be considered to have a pseudonymous identit= +y, and each new channel given a new identity. Channel closures can even be = +coinjoin'd when the other party is cooperating. But ultimately, lightni= +ng usefully solves a problem where participants have semi-long lived paymen= +t endpoints.<br></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D= +"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Jun 28, 2015 at 9:32 A= +M, Raystonn . <span dir=3D"ltr"><<a href=3D"mailto:raystonn@hotmail.com"= + target=3D"_blank">raystonn@hotmail.com</a>></span> wrote:<br><blockquot= +e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= +id;padding-left:1ex">Write coalescing works fine when you have multiple wri= +tes headed to the same (contiguous) location.=C2=A0 Will lightning be usefu= +l when we have more unique transactions being sent to different addresses, = +and not just multiple transactions 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><div><br> +<br> +On 28 June 2015 at 12:29, Benjamin <<a href=3D"mailto:benjamin.l.cordes@= +gmail.com" target=3D"_blank">benjamin.l.cordes@gmail.com</a>> 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'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.><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> +</div></div></blockquote></div><br></div> + +--089e013c6856eb7b49051997276e-- + |