From ron.ohara54 at gmail.com  Mon Jul 18 12:17:17 2016
From: ron.ohara54 at gmail.com (Ron OHara)
Date: Mon, 18 Jul 2016 13:17:17 +0100
Subject: [Lightning-dev] LN question - real life transaction bundling
In-Reply-To: <87bn1vivop.fsf@rustcorp.com.au>
References: <578208C9.4090807@gmail.com> <87bn1vivop.fsf@rustcorp.com.au>
Message-ID: <578CC8CD.1090803@gmail.com>

Thanks for your feedback, but I think there is a lot more to this. 

On 18/07/16 02:25, Rusty Russell wrote:
> Ron OHara <ron.ohara54 at gmail.com> writes:
>> Hi .... forgive me if I have missed something obvious.
>>
>> In the LN whitepaper (like many others) the discussion revolves around
>> Alice and Bob interacting ... fine.
>>
>> IF Alice and Bob interact many times during an interval, there is clear
>> chance to optimize that to a single 'settlement' on the block chain.
>
> Yes, that's a simple payment channel, which have existed for some time.
> They're very limited.

Ack on that  - very limited. I can not see any 'end user' use case (P2P)
where there is a good probability of optimization here.

For B2B, there ARE many repeated interactions that could be optimized,
so that use case might support switching to LN rather than using BTC
directly, but not where one of the parties is a normal consumer.

>
> Lightning adds the ability to trustlessly chain channels, so Alice can
> pay Carol via Bob.
>
>> If the interval is a month ... then since I am fairly predictable...  ,
>> I purchase from the same shops many times in that month... that could be
>> optimized. BUT will the merchants be happy with (up to) a months worth
>> of revenue still pending inside LN?  I dont think so. Visa via the
>> banks, allows merchants access to the pending funds, with the proviso
>> that they may be reversed in the future. Cashflow is vital to merchants.
> Channels are just bitcoins held by a 2 of 2 signature, with a way of
> cashing out (with some delay!) if the other side vanishes.
>
> A recipient doesn't have to actually hold that many bitcoins though,
> since they mainly receive payments.
>
> (Now, there's another question about whether stores will actually do
> this themselves, or outsource to Coinbase etc, just like bitcoin...)

As I understand it, the recipient is still 'pending' settlement to the
blockchain for any funds they receive. That means inwards cashflow (cash
receivable) is unavailable for period of time. This would a big negative
for actual businesses. They could obviate that by outsourcing as you
say, but that outsourcer effectively becomes a bank credit provider to
them if they are given access to the cashflow prior to settlement to the
blockchain.

Even with LN hubs, the sender side (client) does need to tie up funds.
If you want to get optimization, then LN needs to encompass lots of
transactions per client (and receiver) - otherwise it just resolves as
near one-to-one settlement to the blockchain.

What is unclear to me, is which use cases (involving end users), will
have the volume of Tx per user, to justify them reserving funds. Even
though as a user you are not relying on a 3rd party to hold your funds,
those funds are still reserved for your channel or channels, and
unavailable for other usage. That is like saying to my bank (sort of a
hub?) 'even though I have $100, prevent me withdrawing that, just in
case I want to use my Visa card for Tx this month' .... I just do not
believe that people would tolerate that. They have been conditioned by
the current system to expect to be given all sort of tolerance for bad
financial planning. Zero cost overdrafts, with nasty fees if you exceed
the agreed limit, rather than prudent cash planning.

>
>> OK - that is for the Alice and Bob case of interactions.  Now for the
>> other little problem I see here - which makes things even worse.
>>
>> With Bitcoin it is NOT 'Alice transacting with Bob'.
>> It is Address(1) transacting with Address(2) .... and if both parties
>> are following the recommended practice of not re-using addresses, then
>> their next interaction is Address(3) transacting with Address(4) -
>> removing any possibility of optimization.
>>
>> As far as I can tell, long running channels, are by definition identical
>> to address re-use for the period they are open. That makes them very
>> vulnerable to traffic analysis and thus have lower security that native
>> Bitcoin transactions. That is probably acceptable for many use cases,
>> but it is a tradeoff to gain performance.
> Kind of.  It's better, and worse.  If Alice only has one channel, and
> it's to Bob, Bob can see all the amounts Alice spends.  It's fairly easy
> to make sure Bob can't see the final destination (just the next hop),
> but he gets an idea of the amounts.  Nobody else can see it unless Bob
> shows them though, so it's not quite the same as on-chain.
Traffic analysis is a lot more powerful than you seem to realize. Even
in a huge maze of convoluted transactions with many parties involved,
traffic analysis of a system that does not deliberately/randomly delay
interactions easily detects correlations - even when the content is
encrypted. That is precisely how Bletchley Park worked during WWII for
at least half of the information it gleaned. Breaking Enigma was not the
only tactic those guys used.

Like I said, this appears to be an inherent vulnerability. That is not
an issue, as long as it is a known and accepted tradeoff, but that
aspect will reduce the number of use cases where LN is seen as a good fit.

>
> Having three channels is a good idea; it makes the whole system more
> robust, it spreads the information around, *and* because Bob can never
> know then if Alice is actually routing a payment for someone else.
>
> Hope that helps!
> Rusty.

I appreciate the feedback, and want to give you some support in
believing the technical aspects of this can be solved. Why do I believe
that? Because, back in the 1980's I architected and wrote a lot of a
system (TEXAS) that tackled a surprisingly similar scenario, for
Telstra.  It end up being the 4th largest transaction processing system
they had in operation, so I know the technical issues can be dealt with.

I am more concerned about the bootstrap problem LN faces for whatever
use cases are a good fit.

As I see it, LN with hubs (with routing) really only starts to gain
major traffic optimization wins, when it has a lot of channels and
participants..

But how do you get there? A chicken and egg business problem.

Ron


-- 
Talent hits a target no one else can hit, genius hits a target no one
else can see