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 94D3D67 for ; Mon, 10 Aug 2015 17:03:31 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D93B41AB for ; Mon, 10 Aug 2015 17:03:30 +0000 (UTC) Received: from cotinga.riseup.net (unknown [10.0.1.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 55205C2097; Mon, 10 Aug 2015 10:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1439226210; bh=cHv+y+n/epFKoxNIoGHPX1Ez3iXLxf0UXTk2mC5O7Kw=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=Kwhzg3x9hiNw8TKiUG0mxWLz6Xr307lAU6gM/9OdSk0n7iuIjfKeH2I5ac3BrLoj+ HX+qSBStE2jA/sWFWvdtkwCpKZW7mrcnv7A+ivtSOJMFziNOMHezHsZrXs6j/v4z1b vqHX4KOuz1DQWwIP2uYlonFmKysnD3fHUm3p7Lfc= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id C0B731C03A9 Message-ID: <55C8D960.607@riseup.net> Date: Mon, 10 Aug 2015 10:03:28 -0700 From: odinn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Hector Chu , Mark Friedenbach References: <55C79FF0.8040100@thinlink.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=5.0 tests=BAD_CREDIT,BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, UNPARSEABLE_RELAY,URIBL_DBL_ABUSE_REDIR autolearn=no 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 17:03:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, If I understand this correctly, Lightning only requires transaction malleability to be fixed to be able to work ~ I believe that was going to happen in a release of (bitcoind), but I'm not sure if that is correct on timing ( note also, this wiki seems to be out of date on infos about bitcoind https://en.bitcoin.it/wiki/Bitcoind ) I have also heard it said that bitcoin should support relative locktime opcodes so that long-lived micropayment channels would be able to be created, such that there would be Lightning functionality beyond the basic microhop channels (which would be short-lived in nature at the basic level). This would be nice, but it seems like such discussions would take a while to get done as basic development issues right now aren't even wrapping up (e.g. blocksize debate related stuff.) Note that I've been in favor of going ahead with Cameron Garnham's dynamic softfork proposal right now, which can be seen at http://is.gd/DiFuRr - testing it out, seeing how that works, and at the same time making preparations for moving forward with Garzik's BIP 100 (which could be tailored or refined based on additional data gathered, without being turned into a controversial fork (e.g. needs to make sure to avoid inclusion of XT, for example). Garnham's proposal and Garzik's proposal are not mutually exclusive, imho, and I don't see why the matter can't simply be resolved, it seems to be just an endless pile of argumentation that will go on forever and ever. This needs to, like, stop. Also, it strikes me that unless and until certain changes can be made in bitcoin that would reduce fees and cost to transact, solutions such as Lightning are going to fill the gap whether or not you want them to; users have a choice in the market, and as the billions of unbanked are gradually excluded from straight bitcoin, people will seek other services which offer them lesser fees to transact, or they will seek other coins which offer them lesser cost to transact. It is, after all, an open market. I have made this point before elsewhere albeit with more emphasis (and data to back up my point): ( On Github at Pull Request #6201: http://is.gd/8bW0zq ) In making and successfully defending such points on Github, the following conclusions were drawn: As the cost to transact goes higher and higher based on this observable trend (due to all the factors mentioned in the thread on github), then people who are affected by these rising costs to transact will do one of three things with respect to bitcoin (and virtual currencies generally): 1) Ignore bitcoin (an unlikely possibility, but it is one that would occur), 2) adopt alts which are more inclined to allow people to perform microtransactions, 3) and/or use bitcoin increasingly off-chain, which is likely to come with its own set of problems for the network. Regarding donation or microdonation use cases, To keep it all on-chain, wallets can be designed to accumulate donation micro-amounts according to donation settings of a user (in voluntary donation use cases such as in ABIS -- http://abis.io ) as an internal accounting feature, for example, and when enough donation value is accumulated, it can be sent to the recipient by piggybacking on one of the user's daily transactions. This is one method doing so in a manner which is on-chain; depending on the cryptocurrency under consideration, the feasibility of doing this in a wallet will be greater or lesser. - -O On 08/09/2015 01:14 PM, Hector Chu via bitcoin-dev 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? > > On 9 August 2015 at 19:54, Mark Friedenbach via bitcoin-dev > > wrote: > > Tom, you appear to be misunderstanding how lightning network and > micropayment hub-and-spoke models in general work. > >> But neither can Bob receive money, unless payment hub has > advanced it to the channel (or (2) below applies). Nothing > requires the payment hub to do this. > > On the contrary the funds were advanced by the hub on the creation > of the channel. There is no credit involved. if the funds aren't > already available for Bob to immediately claim his balance, the > payment doesn't go through in the first place. > > On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev > > wrote: > > On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote: > >> Don't turn Bitcoin into something uninteresting, please. > > Consider how Bob will receive money using the Lightning Network. > > Bob receives a payment by applying a contract to his local payment > channel, increasing the amount payable to him when the channel is > closed. > > There are two possible sources of funding for Bob's increased > claim. They can appear alone, or in combination: > > > Funding Source (1) A deposit from Bob's payment hub > > Bob can receive funds, if his payment hub has made a deposit to > the channel. Another name for this is "credit". > > This credit has no default risk: Bob cannot just take payment > hub's deposit. But neither can Bob receive money, unless payment > hub has advanced it to the channel (or (2) below applies). > Nothing requires the payment hub to do this. > > This is a 3rd-party dependency totally absent with plain old > bitcoin. It will come with a fee and, in an important way, it is > worse than the current banking system. If a bank will not even > open an account for Bob today, why would a payment hub lock up hard > bitcoin to allow Bob to be paid through a Poon-Dryja channel? > > > Funding Source (2) Bob's previous spends > > If Bob has previously spent from the channel, decreasing his claim > on its funds (which he could have deposited himself), that claim > can be re-increased. > > To avoid needing credit (1), Bob has an incentive to consolidate > spending and income in the same payment channel, just as with > today's banks. This is at odds with the idea that Bob will have > accounts with many payment hubs. It is an incentive for > centralization. > > > With Lightning Network, Bob will need a powerful middleman to send > and receive money effectively. *That* is uninteresting to me. > > > _______________________________________________ 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 > > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVyNlfAAoJEGxwq/inSG8CTvgH/3b4wyoU+hQtQ7Ewk4n1UK/Q gBezGVfv6v9D8uRU+8gR37gG6TpiG3VS37g47fkAbqTTUzY16qGRXMV8mi0FVz/3 8Hqz7rWZEllYfeYrV9MUoNftrFmjy1PucPgd95BYmWaHoZRxBwhr+YpkZS5lfEqK p1byEdqXW04sc3UBdNlirYNOBJA0wOPgco45G2S3gFBh5XQZ9YCLB+x/IN8rW1mS wQ3FrXRdEKfGMZ83xij1zOVpwi3bPJ5XrUzEV3sdGUdj6jWi0Pa05tRD+0qt7dpZ oPq4p6aLj2z5/mwyiaW6T14CNY1Mp46tMgAv+BOJ/M3HA350isTGxG2X+73KeH0= =xX4u -----END PGP SIGNATURE-----