summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRaystonn . <raystonn@hotmail.com>2015-06-28 09:32:05 -0700
committerbitcoindev <bitcoindev@gnusha.org>2015-06-28 16:32:50 +0000
commit58422735f2fa57d195dacf024f7bbaada2d1746f (patch)
tree884dc7071760ea1e9dc01452771ce6f2e9949fab
parent63e9b08bc5ed80505730a6dbf03a773aa2f3974d (diff)
downloadpi-bitcoindev-58422735f2fa57d195dacf024f7bbaada2d1746f.tar.gz
pi-bitcoindev-58422735f2fa57d195dacf024f7bbaada2d1746f.zip
Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
-rw-r--r--bc/295afedf9b7dd6d205ec2afce4d554eab79b2499
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
+
+