diff options
author | Raystonn . <raystonn@hotmail.com> | 2015-06-28 09:32:05 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-28 16:32:50 +0000 |
commit | 58422735f2fa57d195dacf024f7bbaada2d1746f (patch) | |
tree | 884dc7071760ea1e9dc01452771ce6f2e9949fab | |
parent | 63e9b08bc5ed80505730a6dbf03a773aa2f3974d (diff) | |
download | pi-bitcoindev-58422735f2fa57d195dacf024f7bbaada2d1746f.tar.gz pi-bitcoindev-58422735f2fa57d195dacf024f7bbaada2d1746f.zip |
Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
-rw-r--r-- | bc/295afedf9b7dd6d205ec2afce4d554eab79b24 | 99 |
1 files changed, 99 insertions, 0 deletions
diff --git a/bc/295afedf9b7dd6d205ec2afce4d554eab79b24 b/bc/295afedf9b7dd6d205ec2afce4d554eab79b24 new file mode 100644 index 000000000..3cc5497df --- /dev/null +++ b/bc/295afedf9b7dd6d205ec2afce4d554eab79b24 @@ -0,0 +1,99 @@ +Return-Path: <raystonn@hotmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 31217273 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 28 Jun 2015 16:32:50 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from COL004-OMC4S1.hotmail.com (col004-omc4s1.hotmail.com + [65.55.34.203]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B65EC112 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 28 Jun 2015 16:32:49 +0000 (UTC) +Received: from COL131-DS8 ([65.55.34.199]) by COL004-OMC4S1.hotmail.com over + TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); + Sun, 28 Jun 2015 09:32:49 -0700 +X-TMN: [CPdStZQiv8P0zCBCSTkRtQP4HaRMJrcd] +X-Originating-Email: [raystonn@hotmail.com] +Message-ID: <COL131-DS8E3DCDBD1A0F359206781CDAB0@phx.gbl> +From: "Raystonn ." <raystonn@hotmail.com> +To: "Adam Back" <adam@cypherspace.org>, + "Benjamin" <benjamin.l.cordes@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> +In-Reply-To: <CALqxMTGXcbES5Pwz3cWO+PQK5kmf3rZ_i00=b=PBnO678XuF0A@mail.gmail.com> +Date: Sun, 28 Jun 2015 09:32:05 -0700 +MIME-Version: 1.0 +Content-Type: text/plain; format=flowed; charset="iso-8859-1"; + reply-type=original +Content-Transfer-Encoding: 7bit +X-Priority: 3 +X-MSMail-Priority: Normal +Importance: Normal +X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 +X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 +X-OriginalArrivalTime: 28 Jun 2015 16:32:49.0668 (UTC) + FILETIME=[128AFC40:01D0B1C0] +X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM, + RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD, + STOX_REPLY_TYPE 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 16:32:50 -0000 + +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 + + |