Re: [bitcoin-dev] What Lightning Is

From: odinn <odinn.cyberguerrilla@riseup•net>
To: Hector Chu <hectorchu@gmail•com>,
	Mark Friedenbach <mark@friedenbach•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] What Lightning Is
Date: Mon, 10 Aug 2015 10:03:28 -0700	[thread overview]
Message-ID: <55C8D960.607@riseup.net> (raw)
In-Reply-To: <CAAO2FKHyNC6PT+i2pYo88eeb-wdkJdeVjmqzC=PetyF6yO=+Lw@mail.gmail.com>

-----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 
> <bitcoin-dev@lists•linuxfoundation.org 
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> 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 
> <bitcoin-dev@lists•linuxfoundation.org 
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> 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 
> <mailto:bitcoin-dev@lists•linuxfoundation.org> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation.org 
> <mailto: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-----