Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-07-17 📝 Original message: Ron OHara <ron.ohara54 at ...
📅 Original date posted:2016-07-17
📝 Original message:
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.
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...)
> 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.
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.
📝 Original message:
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.
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...)
> 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.
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.