Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EF8808C7 for ; Mon, 10 Aug 2015 04:48:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9807913B for ; Mon, 10 Aug 2015 04:48:43 +0000 (UTC) Received: by pawu10 with SMTP id u10so131413122paw.1 for ; Sun, 09 Aug 2015 21:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightning.network; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=QG+XdeaWkPhVg14yzcFUx92vxCVFyWSipuChEKFPfrk=; b=XKJqzY0tSY4zvN1h2EKuyRrWBLDjqbREo5fp975ye9F2h7VhB80sVaKNQjaEJHjDTC X47YtlvBRrPMVflCkWYHHVBsNXEYf3MVy5cxXUHvRvqNAxPsJWyeLf7uWW9pYd/HB2ad vGcsiYxbQ6Ue+ZluXZjcy5GJKXdv5OWgviQ/w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to; bh=QG+XdeaWkPhVg14yzcFUx92vxCVFyWSipuChEKFPfrk=; b=Dzy2dLnFEPMZgxPG5iuBwGLzqHhDdv8rRhSKGa0I7MbhIlncd7gkqtsHDeMi+0/BjA IDjZPKXXRvwVj0XhgMaaCPnWKOba3jmee5lxj77BChsblEtIT6d4zBnO+gKdRBCZ68AX WibLDknd66aXm3OUeAcUDF2HkyV0pf6oAWSG6q1fUfpItluZ8k49jtpP7Sw4pTCCFaE2 rhZrb7kS7phe6DDxL/vjKbqjzzy1z/Jg3RmML0c8Xs2sLdczli6+K6UT1BX0oHqLJOiD IYZqn+UqvWxB62bqYedkphMfTljzLvNQxW2kyi4iTp8oNsUAKzJ0w+p3SL3dZ/8aXCL1 tWPQ== X-Gm-Message-State: ALoCoQnBOzoZIoc0xHM8n0eAztd6Py4PSii1mpmRBKYkekOhmkDRxOCY0sh5HXAd46EjvUAkYf+v X-Received: by 10.68.205.232 with SMTP id lj8mr41264922pbc.116.1439182123329; Sun, 09 Aug 2015 21:48:43 -0700 (PDT) Received: from localhost ([209.141.33.28]) by smtp.gmail.com with ESMTPSA id bd5sm18107070pbb.85.2015.08.09.21.48.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Aug 2015 21:48:42 -0700 (PDT) Date: Sun, 9 Aug 2015 21:48:28 -0700 From: Joseph Poon To: Hector Chu Message-ID: <20150810044828.GC1758@lightning.network> References: <55C79FF0.8040100@thinlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 Subject: Re: [bitcoin-dev] What Lightning Is 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: Mon, 10 Aug 2015 04:48:44 -0000 Hi Hector, On Sun, Aug 09, 2015 at 09:48:41PM +0100, Hector Chu via bitcoin-dev wrote: > Is the Lightning system limited in the number of hops there can be in > the payment channel? I am looking at the initial Lightning slides > presented in February and it looks like the locktime decrements by > 1-day along each hop. So the more hops there are the longer my > bitcoins are potentially locked up for? The hops are limited to the time-value which the sender wishes to pay and the minimum acceptable timeout between each hop. It should be relatively cheap if you game it out, though (I don't forsee me opening a 1 BTC channel and being able to make $5 per month...) 1-day is used as a convenience. However, the time between hops should be somewhat long, as the intermediate steps can be extended further when you want to offload the HTLCs to others who have a channel open with both counterparties. E.g. Alice sends a payment to Dave through Bob and Carol. Bob has a channel with Carol and has an HTLC with it, but that channel seems to be used a lot. Erin has a relationship to both Bob and Carol, she can offload the payment so that the payment actually goes to A->B->E->C->D. B<->C is now completely clear. > > On Aug 9, 2015 1:15 PM, "Hector Chu" wrote: > >> In the Lightning network it is assumed that the balances can always > >> be settled on the blockchain if any of the parties along the > >> channel has a problem. What if the fee on the settlement > >> transactions is not high enough to enter the blockchain? You can't > >> do replace-by-fee after the fact. Do the fees always have to assume > >> worst case scenarios on the Bitcoin fee market? How do you send coins if you wanted to send funds below the current IsStandard value? It should be no different. If your wallet can't send funds below the IsStandard value on-chain today, then I don't think it should be able to to in the future, right? If you send funds *at* the minimum IsStandard value today, you're probably paying really high fees, this is a problem that exists today. -- Joseph Poon