Re: [Lightning-dev] An Idea to Improve Connectivity of the Graph

[Christian Decker]

ZmnSCPxj via Lightning-dev 
writes:
> In a retaliation construction, if a party misbehaves, the other party gets 
> the entire amount they are working on together, as disincentive for any party 
> to cheat.
>
> That works for the two-party case A and B.  If A cheats, B gets money.
>
> How do you extend that to the three-party case A B C?  If A cheats, what 
> happens?
>
> Suppose the correct current state is A=2, B=99, C=3.  Suppose A cheats
> and attempts to publish A=102, B=1, C=1.  C detects it because B is
> asleep at that time.  Does C get to claim the money that A claimed for
> itself, basically 101+1 and thus 102?  But the correct state has
> almost all of the money assigned to B instead.  Obviously that is
> unjust.  Instead C should get to claim only 3 from A (its 3 in the
> final state) in addition to its 1 in the published state, and should
> give the 99 to B.  So now B also needs another retaliatory
> construction for the case "A cheated first and C found out and and
> also cheated me", and a separate construction for "A cheated but C was
> honest".  And that is separate construction for the case "C cheated
> first and A found out and also cheated me" and a separate construction
> for "C cheated but A was honest".
>
> As should be obvious, it does not scale well with number of
> participants on a single offchain "purse"; it quickly becomes complex
> fast.

The need to identify the misbehaving party and punish just that one
party could be addressed by having pre-committed retaliation
transactions. However this results in a large number of pre-committed
transactions that need to be carried around just for the case that
someone really misbehaves. In addition colluding parties may be able to
punish each other when an cheat attempt seems doomed to fail, which
reduces the cost of the attack. This could also be partially fixed by
pre-committing retaliation transactions that split the misbehaving
party's funds. Overall a very unsatisfactory solution.

> Retaliatory constructions however have the major advantage of not
> imposing limits on the number of updates that are allowed to the
> offchain "purse".  Prior to Rusty shachains it was thought to require
> storage linear in the number of updates (which could be pruned once
> the channel/"purse" is brought onchain), but Rusty shachains also
> require O(1) storage on number of updates.  Thus retaliatory
> constructions are used for channels.
>
> Note that channel factories, to my understanding, can have the Duplex
> construction near the root of the initial onchain anchor transaction,
> but be terminated in Poon-Dryja retaliatory channels, so that a good
> part of the current LN technology has a good chance of working even
> after channel factories are implemented.  This strikes me as a good
> balance: restructuring channels is expected to be much rarer compared
> to updating them normally for normal usage, so each construction plays
> its own strengths: the Decker-Wattenhofer construction which imposes a
> limit on the number of updates, but has no limit on number of
> participants, is used for the rarer. massive "channel restructuring"
> operations, while the Poon-Dryja construction which imposes a
> practical limit on number of particiapnts, but has no limit on number
> of updates, is used for "day-to-day" normal operation.

That's not as bad a tradeoff as people usually interpret, the DMC
construction has parameters that allow tweaking the number of
invalidations, and with parameters similar to LN we can have 1.4 billion
updates. Which is years of operation without need to
re-anchor. In addition penaltyless invalidation has a number of
advantages, for example it doesn't have the state asymmetry inherent in
LN and there is no toxic state information that, when leaked, results in
your funds being claimed through a retaliation. This happened to me btw
last month when I accidentally restored a wallet from backup and
attempted to reconnect.

Cheers,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Lightning over NFC

[Igor Cota]

Morning all,


> However it seems to me that the payer will need a direct channel to the
payee, or at least the payment terminal (of the payee...?).

Yes, for the lightning NFC connection I had the local coffe shop use case
in mind.


> The trusted server can, for instance, be a full Lightning node running at
the payer's home.

This is my current setup and I feel the only feasible one for the privacy
minded. For the time being at least.


> The payer then only has to take a very light piece of electronics with
him/her. It will still be larger than a credit card (since authentication
should be done payer-side, e.g. with a PIN code), but it can be smaller
than a smart phone.

This is a great idea!


> But what the payment terminal would provide, would not be a connection to
the payment terminal node, but a connection to the Internet-in-general.

¿Por qué no los dos?
I'm thinking of a protocol where (after initial BOLT-11 transfer) the
terminal and device agree on the means of connection depending on what they
respectively support or makes sense at that moment. There is a standard way
for NFC to handover to bluetooth or wifi, I'll look into that. Basically
whatever works as long as it seems seamless to the user and is relatively
quick.

I'm not so fussed about potential abuse for these types of payments. In my
experience people are less likely to scam you if you are physically there.
:)

Thanks for your input! I made a pull request for the BOLT-11 MIME type and
I'll have a think-over bout the connection-handover business.

Cheers,
Igor



On 5 April 2018 at 18:53, ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Good morning Corne,
>
> My understanding, of the setup of Igor, is that, there is a
> Lightning-protocol connection between the mobile device and the base
> station/payment terminal device.
>
> Initiating a payment to anyone on the network requires that you have
> direct communication with whoever you have a direct channel to.
>
> If the mobile device can communicate only with the payment terminal, then
> it can only pay using channels with the only node it has a connection to.
>
> The mobile device could pay anyone else on the network via that channel,
> but presumably the purpose of the payment terminal is to be the node that
> receives the payment.
>
> If the payment terminal itself connects to anyone else, on behalf of the
> mobile device, then that is beyond the current Lightning protocol.  Perhaps
> Igor has added more messages that allow such a setup?
>
> Communicating over a secure channel to a trusted server is how I imagine
> most practical mobile devices would work.  But what the payment terminal
> would provide, would not be a connection to the payment terminal node, but
> a connection to the Internet-in-general.
>
> Regards,
> ZmnSCPxj.
>
>
> ​Sent with ProtonMail Secure Email.​
>
> ‐‐‐ Original Message ‐‐‐
>
> On April 5, 2018 11:52 PM, Corné Plooy via Lightning-dev <
> lightning-dev@lists.linuxfoundation.org> wrote:
>
> > If there are censorship concerns, you could opt for a set-up where payer
> >
> > has an authenticated connection to a trusted server, through the
> >
> > Internet connection provided by payee. The trusted server can, for
> >
> > instance, be a full Lightning node running at the payer's home.
> >
> > The payer then only has to take a very light piece of electronics with
> >
> > him/her. It will still be larger than a credit card (since
> >
> > authentication should be done payer-side, e.g. with a PIN code), but it
> >
> > can be smaller than a smart phone. Personally, I like this kind of
> >
> > set-up, because I see cell phones as a huge privacy issue (you're
> >
> > continuously transmitting your rough location to the network).
> >
> > Why would there need to be a direct channel between payer and payee? We
> >
> > have the Lightning network to avoid needing direct channels, right?
> >
> > CJP
> >
> > Op 05-04-18 om 17:39 schreef ZmnSCPxj via Lightning-dev:
> >
> > > Good morning Igor,
> > >
> > > This is quite an interesting use-case for Lightning.
> > >
> > > However it seems to me that the payer will need a direct channel to
> > >
> > > the payee, or at least the payment terminal (of the payee...?).
> > >
> > > In addition the payer will need to somehow get blockchain information
> > >
> > > from the payee if the payer itself has no Internet.  The payee may
> > >
> > > have an incentive to prevent the payer from knowing that timeouts have
> > >
> > > been reached, for example, and may withhold new blocks (although all
> > >
> > > censorship attacks I know of that could be used on LN target the payee
> > >
> > > and not the payer).
> > >
> > > Is my understanding correct?
> > >
> > > Regards,
> > >
> > > ZmnSCPxj
> > >
> > > Sent with ProtonMail https://protonmail.com Secure Email.
> > >
> > > ‐‐‐ Original Message ‐‐‐
> > >
> > > On April 5, 2018 5:46 PM, Igor Cota i...@codexapertus.com wrote:
> > >
> > > > Hello all,
>