From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 55D79B13 for ; Fri, 10 Jul 2015 02:55:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0082710D for ; Fri, 10 Jul 2015 02:55:16 +0000 (UTC) Received: by pdbqm3 with SMTP id qm3so31992983pdb.0 for ; Thu, 09 Jul 2015 19:55:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4fyx77CaHPBS+svsfpi0NlRG51NzwDyg6XIfBSHedA0=; b=BaNS09LGMVaBACDC9xR3VC8Ob7AXJpUhlySXvKYLEasJHo9fzeN7yb8YoqwONmo7ze Gh1aRg8FNzlD85OUyH/LVOLnz1aWsQVPslw4LWejBJUOdbfQfKU61vUIG/1NvWIQc9Kh ft3VIH6rpeZzh3l5obKcoSyxPCy4RvmWTrKfDL2j3BPRLox8IT7Ppfl6d0NlEmOI/bM9 uRuaIWRXblM9EsFNIVbxH+xK09+I6vPQDfjGAKIXK02AavEm7MP+wNHJ7KyHwuY7cMKQ 90nyzL4p+6DGf5JMAcBmXw4iEmXwcc+50I2vP+e0sllwCXo4wTx8ERngnWkvZRtq2dfx eCbw== X-Gm-Message-State: ALoCoQnaPJ0kWrUekheVT1jSi75tQ95L3USv8IrhCW5LZIuznipEEZaMKAbCixkD/yfEXXmv8d/m X-Received: by 10.70.43.72 with SMTP id u8mr37361804pdl.33.1436496916753; Thu, 09 Jul 2015 19:55:16 -0700 (PDT) Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net. [99.8.65.117]) by smtp.googlemail.com with ESMTPSA id w3sm1051252pdl.45.2015.07.09.19.55.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2015 19:55:15 -0700 (PDT) Message-ID: <559F3413.6040307@thinlink.com> Date: Thu, 09 Jul 2015 19:55:15 -0700 From: Tom Harding User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Adam Back References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 02:55:17 -0000 >> On 6/28/2015 9:32 AM, Raystonn . 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. > On 6/28/2015 10:29 AM, Gavin Andresen wrote: >> Don't get me wrong, I think the Lightning Network is a fantastic idea >> and a great experiment and will likely be used for all sorts of great >> payment innovations (micropayments for bandwidth maybe, or maybe >> paying workers by the hour instead of at the end of the month). But I >> don't think it is a scaling solution for the types of payments the >> Bitcoin network is handling today. On 6/28/2015 11:58 AM, Adam Back wrote: > Lightning allows Bitcoin to scale even without a block-size increase, > and therefore considerably impacts any calculation of how much > block-size is required. In this light you appear to have been > attempting to push through a change without even understanding the > alternatives or greater ecosystem. Lightning Network (LN) does not "allow Bitcoin to scale". LN is a bitcoin application. The properties of LN are dependent on bitcoin, but they are distinct from bitcoin. In particular, an under-appreciated aspect of LN is that in order for your interactions to be consolidated and consume less blockchain space, you must give up significant control of the money you send AND the money you receive. If either sender or receiver wants to record a transaction in the blockchain immediately, there is no space savings versus bitcoin. More blockchain space is actually, used, due to LN overhead. If both sender and receiver are willing to delay recording in the blockchain, then the situation is analogous to using banks. Sender's hub pays from sender channel, to receiver channel at receiver's hub. Neither side fully relinquishes custody of the money in their multisig payment hub channels -- this is an improvement on traditional bank accounts -- BUT... - Sender is required to lock funds under his hub's signature - this is well discussed - Less well discussed: *to achieve any consolidation at all, receiver must ALSO be willing to lock received funds under his hub's signature* I'll put it another way. LN only "solves" the scaling problem if receiver's hub has pre-commited sufficient funds to cover the receipts, AND if receiver endures for a period of time -- directly related to the scaling factor -- being unable to spend money received UNLESS his payment hub signs off on his spend instructions.