Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...

[Andrés G . Aragoneses]

Hello Matt, can you clarify what you mean with this particular paragraph?:

But for some reason those pesky users keep wanting to use lightning for
> tips, or at least accept
> payment on their phones without keeping them unlocked with the lightning
> app open on the foreground
> 24/7.


So the use case here is more narrow? You mean that the recipient is a
mobile user that has his phone locked?
Just so I understand better what the problem is.


On Wed, 13 Oct 2021 at 12:44, Matt Corallo  wrote:

> I'm sure most of y'all are familiar with this problem by now - a lightning
> user on a phone trying to
> pay another lightning user on a phone requires some amount of coordination
> to ensure the sender and
> recipient are, roughly, online at the same time.
>
> Invoices provide this somewhat today by requiring the recipient provide
> some live-ish data to the
> sender with their phone in their hand.
>
> But for some reason those pesky users keep wanting to use lightning for
> tips, or at least accept
> payment on their phones without keeping them unlocked with the lightning
> app open on the foreground
> 24/7.
>
> There's a few things live today which make progress towards this goal, but
> don't quite get there
> (and mostly aren't trying to solve this problem, but are worth mentioning):
>
>   * just have the recipient use a custodial product/run a full lightning
> node at home on an RPi.
> Obviously this has some pretty substantial drawbacks, I'm not sure I
> even need to list them, but
> the "just require the recipient use a custodial service" is what Twitter
> ended up shipping with for
> lightning tipping, and we should all probably feel ashamed that they felt
> the need to do that.
>
>   * Blockstream Greenlight.
> This change the online-requirements model - with the keys on your
> phone/elsewhere you still have
> to have your phone online with the same requirements as running a full
> lightning node. It just means
> fewer resources on that device.
>
>   * use keysend/AMP/whatever.
> This is great for tips, but only half the story. Sender goes to send a
> keysend payment, gets to
> one hop before the recipient, and then a day later the recipient comes
> online to find the payment
> long-since timed out and failed backwards. Or you could use a long CLTV on
> the payment to make sure
> the recipient has time to claim it, which is basically a DoS on the
> lightning network's capacity,
> one that may eventually be fixed, breaking your payments, and which is
> just generally antisocial.
> Still, my understanding is some folks do this today cause its the only
> option for a mobile device.
>
>   * lnurl
> ...is a great way to get an invoice, presumably from a trusted LSP for
> the recipient, trusting
> them to not give the same invoice twice, but doesn't help the recipient
> receive the payment, they
> still need to be online, unless...
>
>   * have a fully-trusted LSP that accepts payments and forwards them later
> this is also fine, where its practical, I guess, but I'd hope we can
> do better. Worse, as far as
> I understand the places where this is practical are becoming fewer and
> fewer as the regulatory
> uncertainty clears and everyone realizes the regulatory overhead of this
> is...well you might as well
> start applying for that banking charter now.
>
>   * have an untrusted LSP that sends you a notification to open the app
> when a payment is received
> Several lightning apps do this today, and its somewhat of a stop-gap
> but does help. On platforms
> where the app gets some meager CPU time in response to a notification,
> this can even fully solve the
> problem by claiming the HTLC in response to the notification pushed
> out-of-band. Sadly, the refrain
> I've heard repeatedly is, these days, on both Android and especially iOS,
> you can't even rely on a
> microsecond of CPU time in response to a notification. The OS fully
> expects your app to run code
> only when its on and in the foreground, unless you're a VoIP app you're
> screwed. Relying on the user
> to open the app immediately when they receive a notification is...fine, I
> guess, absent a better
> idea it seems like the best we've got today, but I'm not sure you'd find a
> UX designer who would
> *suggest* this :).
>
>
> But what would it take to do better? What follows is a simple straw-man,
> but something that's
> borderline practical today and may at least generate a few ideas. It comes
> in two variants
>
> If we accept the lnurl trust model of "a third-party I can give a list of
> pre-signed invoices, which
> I trust to never provide an invoice twice, but otherwise is untrusted",
> then we could do something
> like this:
>
> Step 1. Tipper gets an invoice from the lnurl endpoint they wish to pay,
> which contains some
> "recipient is behind an LSP and rarely online, act accordingly" flag.
>
> Step 2. Tipper sender sends a HTLC with a long CLTV timeout to their own
> LSP with instructions
> saying "when you get 

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

[Andrés G . Aragoneses]

Completely agree with this. How to move this forward? Set up a vote? What
would be the reasoning for not moving it?

On Fri, 8 Oct 2021 at 23:25, Fabrice Drouin  wrote:

> Hello,
>
> When you navigate to https://github.com/lightningnetwork/ you find
> - the Lightning Network white paper
> - the Lightning Network specifications
> - and ... the source code for lnd!
>
> This has been an anomaly for years, which has created some confusion
> between Lightning the open-source protocol and Lightning Labs, one of
> the companies specifying and implementing this protocol, but we didn't
> do anything about it.
>
> I believe that was a mistake: a few days ago, Arcane Research
> published a fairly detailed report on the state of the Lightning
> Network: https://twitter.com/ArcaneResearch/status/1445442967582302213.
> They obviously did some real work there, and seem to imply that their
> report was vetted by Open Node and Lightning Labs.
>
> Yet in the first version that they published you’ll find this:
>
> "Lightning Labs, founded in 2016, has developed the reference client
> for the Lightning Network called Lightning Network Daemon (LND)
> They also maintain the network standards documents (BOLTs)
> repository."
>
> They changed it because we told them that it was wrong, but the fact
> that in 2021 people who took time do do proper research, interviews,
> ... can still misunderstand that badly how the Lightning developers
> community works means that we ourselves badly underestimated how
> confusing mixing the open-source specs for Lightning and the source
> code for one of its implementations can be.
>
> To be clear, I'm not blaming Arcane Research that much for thinking
> that an implementation of an open-source protocol that is hosted with
> the white paper and specs for that protocol is a "reference"
> implementation, and thinking that since Lightning Labs maintains lnd
> then they probably maintain the other stuff too. The problem is how
> that information is published.
>
> So I'm proposing that lnd's source code be removed from
> https://github.com/lightningnetwork/ (and moved to
> https://github.com/lightninglabs for example, with the rest of their
> Lightning tools, but it's up to Lightning Labs).
>
> Thanks,
>
> Fabrice
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Zero Fee Routing

[Andrés G . Aragoneses]

How is this related to the youtube video posted? Can you link to a specific
time in it where it is discussed?

On Sun, 15 Aug 2021 at 00:30, Daki Carnhof  wrote:

> This text was brought to life by repelling magnet forces of reading
> ZmnSCPxj's Algorithm For Channel Fee Settings. Thank you, Zmn! Bitcoin
> has taught me to just do nothing and it would probably be preferable in
> this case as well, but here is my 5msat.
>
> # Introduction
>
> Zero Fee Lightning Network Routing (both 0/0) is an alternative way of
> looking at channel fee settings. The philosophical idea behind it is based
> on the fact that by encouraging individuals to do their own (automated) fee
> management we are actually forcing everyone individually to do the
> decisions which are are currently done in fiat (and altcoin) standard
> through interventions. And which we oppose by Bitcoin.
>
> # Reasoning
>
> See discussion with Jordan P. Peterson and guests at
> https://www.youtube.com/embed/iVym9wtopqs
>
> Our computers are running anyway for the Bitcoin nodes. They do quite a
> lot of  simple computations for free* already. If it did not make sense,
> the nodes would not be run. The same reasoning extends to zero fee routing
> on LN. In our opinion it is much more straightforward to not ask for fees
> on LN. The higher interest of the community will just melt into the overall
> price, like Proof-of-Work does. Using an algorithm like Hill Climbing would
> just make our computers compute even more and with uncertain results.
>
> * Without any immediate effect on the amount of satoshi the operator of
> the node owns.
>
> That's it. If I Had More Time, I Would Have Written a Shorter Letter.
>
> Regards,
> Daki
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Escrow Over Lightning?

[Andrés G . Aragoneses]

Hey ZmnSCPxj,

On Fri, 12 Feb 2021 at 08:52, ZmnSCPxj  wrote:

> Good morning Andres,
>
> > Hey ZmnSCPxj,
> >
> > On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj  wrote:
> >
> > > Good morning Andres,
> > >
> > > > This looks cool but would hinder UX too much for certain scenarios:
> e.g. if the escrow in place is part of a bitcoin exchange, then you require
> the bitcoin buyer to have bitcoin already, which makes it harder to on-ramp
> new users (which could maybe only have fiat). Am I right?
> > >
> > > Correct.
> > > Though note that existing systems like Bisq, to my knowledge, have the
> same problem, a buyer of Bitcoin has to have a small amount of Bitcoin to
> offer as stake that can be revoked in case they attempt to defraud the
> counterparty.
> > > Without it, the counterparty takes on increased risk (which translate
> to larger exchange spread).
> >
> > Yeah I understand Bisq's model.
> > However not all P2P exchanges work like this; e.g. localcryptos,
> hodlhodl, localbitcoins, localcryptos...
> >
>
> At least localbitcoins is custodial, and this scheme is non-custodial
> (though the escrow must still be trusted to actually judge correctly in
> case of dispute, so non-custodiality might be a very thin assurance).
>
>
True, I shouldn't have included LB in that list of examples; the other two
are non-custodial though.



> >
> >
> > > In any case, once you have that initial stake, you can then keep
> increasing your ability to provide stake so as to relieve your
> counterparties of risk and have them offer better exchange rates, so it is
> "only" an issue for initial onboarding.
> > > Presumably, in the later stable state, parents will provide children
> the initial stake needed for them to start transacting over such a system,
> just as they already provide their children with other "initial stakes"
> (education, food, shelter, etc.) anyway.
> > >
> > > >
> > > > So are you saying that this is not doable without PTLCs (with simple
> HTLCs) unless it's done like suggested?
> > >
> > > Yes, it is yet another reason we want PTLCs quickly.
> > >
> > > An alternative would be to have dual-hash HTLCs, which would be
> helpful in other escrow-related cases including escrow-facilitated
> cross-currency swaps.
> >
> > Is there any disadvantage about using dual-hash HTLCs?
> > Is it supported by the current LN spec?
>
> It is no supported by current LN spec, and PTLCs are overall superior
> (they are equivalent to having any number of hashes, not just 2 that
> dual-hash HTLCs can do).
> So if we need to change the LN spec anyway, PTLCs are still the better
> choice, since they enable a lot more, and we probably want to support that
> in the future anyway, so we might as well do HTLC->PTLC rather than
> HTLC->2HTLC->PTLC.
>

But anyway any L2 wallet that interacts with this, will need to be aware of
the escrow, so developing an 2HTLC extension for it to work with the
current version of bitcoin (instead of waiting for Taproot) should be
doable, right?



>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Escrow Over Lightning?

[Andrés G . Aragoneses]

Hey ZmnSCPxj,

On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj  wrote:

> Good morning Andres,
>
> > This looks cool but would hinder UX too much for certain scenarios: e.g.
> if the escrow in place is part of a bitcoin exchange, then you require the
> bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new
> users (which could maybe only have fiat). Am I right?
>
> Correct.
> Though note that existing systems like Bisq, to my knowledge, have the
> same problem, a buyer of Bitcoin has to have a small amount of Bitcoin to
> offer as stake that can be revoked in case they attempt to defraud the
> counterparty.
> Without it, the counterparty takes on increased risk (which translate to
> larger exchange spread).
>

Yeah I understand Bisq's model.
However not all P2P exchanges work like this; e.g. localcryptos, hodlhodl,
localbitcoins, localcryptos...



>
> In any case, once you have that initial stake, you can then keep
> increasing your ability to provide stake so as to relieve your
> counterparties of risk and have them offer better exchange rates, so it is
> "only" an issue for initial onboarding.
> Presumably, in the later stable state, parents will provide children the
> initial stake needed for them to start transacting over such a system, just
> as they already provide their children with other "initial stakes"
> (education, food, shelter, etc.) anyway.
>
> >
> > So are you saying that this is not doable without PTLCs (with simple
> HTLCs) unless it's done like suggested?
>
> Yes, it is yet another reason we want PTLCs quickly.
>
> An alternative would be to have dual-hash HTLCs, which would be helpful in
> other escrow-related cases including escrow-facilitated cross-currency
> swaps.
>

Is there any disadvantage about using dual-hash HTLCs?
Is it supported by the current LN spec?



>
> Regards,
> ZmnSCPxj
>
>
> >
> > On Thu, 11 Feb 2021 at 14:01, ZmnSCPxj  wrote:
> >
> > > Good morning Nadav and Andres,
> > >
> > > Thank you for bringing up this topic again.
> > >
> > > Let me provide a new twist to this old idea.
> > >
> > > This is the entire logic of the contract to the seller:
> > >
> > >SELLER && (BUYER || ESCROW)
> > >
> > > Now, a big issue is that simple `&&` is trivial for PTLCs, it is the
> `||` which is difficult and requires ECDH and proof that the ECDH was done
> correctly.
> > >
> > > But we can observe the De Morgan Theorem:
> > >
> > >A || B <=> !(!A && !B)
> > >
> > > So how about we *invert* the logic?
> > >
> > > So what we do is, we make *two* payments of the same amount:
> > >
> > > * Seller -> Buyer , claimable by BUYER && ESCROW key.
> > > * Buyer  -> Seller, claimable by SELLER key.
> > >
> > > So the ritual is this:
> > >
> > > * Seller -> Buyer claimable by BUYER && ESCROW.
> > > * Buyer -> Seller claimable by SELLER.
> > > * Seller hands over item.
> > > * Buyer judges whether to accept, or complain to Escrow.
> > >
> > > Now let us consider our cases:
> > >
> > > * Buyer is satisfied with the product.
> > >   * Buyer fails the Seller->Buyer payment after seller claims the
> Buyer->Seller payment, so Seller is paid and has no more obligations.
> > > * Buyer is dissastisfied and wants the Escrow to judge:
> > >   * Escrow judges Buyer is right: Escrow reveals ESCROW key to Buyer,
> who then clawbacks the payment to the seller.
> > >   * Escrow judges Seller is right: Escrow deletes ESCROW privkey ("not
> ESCROW"), and the Seller->Buyer payment eventually times out, ending the
> obligation of the Seller.
> > >
> > > The "reverse" payment is effectively the inversion of logic by the De
> Morgan theorem, and the "normal case" (buyer ultimately pays seller) has
> the Escrow not revealing the privkey.
> > > In addition, in the case where Buyer is satisfied (i.e. both Buyer and
> Seller agree the trade is beneficial) the Escrow is never involved (the
> Escrow might have a timeout for the temporary ESCROW keypair, which it will
> eventually delete; since all payments on LN need a timeout anyway, this is
> fine) and thus does not know about the trade, except that some trade was
> requested (since it must provide a temporary ESCROW pubkey).
> > >
> > > This even provides a simple BUYER + ESCROW keypair that gives the
> seller a proof-of-refund, and of course the simple SELLER gives the buyer a
> proof-of-payment as well.
> > > It only just requires twice as much Bitcoins getting locked.
> > >
> > > Thoughts?
> > >
> > > Regards,
> > > ZmnSCPxj
>
>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Escrow Over Lightning?

[Andrés G . Aragoneses]

This looks cool but would hinder UX too much for certain scenarios: e.g. if
the escrow in place is part of a bitcoin exchange, then you require the
bitcoin buyer to have bitcoin already, which makes it harder to on-ramp new
users (which could maybe only have fiat). Am I right?

So are you saying that this is not doable without PTLCs (with simple HTLCs)
unless it's done like suggested?

On Thu, 11 Feb 2021 at 14:01, ZmnSCPxj  wrote:

> Good morning Nadav and Andres,
>
> Thank you for bringing up this topic again.
>
> Let me provide a new twist to this old idea.
>
> This is the entire logic of the contract to the seller:
>
>SELLER && (BUYER || ESCROW)
>
> Now, a big issue is that simple `&&` is trivial for PTLCs, it is the `||`
> which is difficult and requires ECDH and proof that the ECDH was done
> correctly.
>
> But we can observe the De Morgan Theorem:
>
>A || B <=> !(!A && !B)
>
> So how about we *invert* the logic?
>
> So what we do is, we make *two* payments of the same amount:
>
> * Seller -> Buyer , claimable by BUYER && ESCROW key.
> * Buyer  -> Seller, claimable by SELLER key.
>
> So the ritual is this:
>
> * Seller -> Buyer claimable by BUYER && ESCROW.
> * Buyer -> Seller claimable by SELLER.
> * Seller hands over item.
> * Buyer judges whether to accept, or complain to Escrow.
>
> Now let us consider our cases:
>
> * Buyer is satisfied with the product.
>   * Buyer fails the Seller->Buyer payment after seller claims the
> Buyer->Seller payment, so Seller is paid and has no more obligations.
> * Buyer is dissastisfied and wants the Escrow to judge:
>   * Escrow judges Buyer is right: Escrow reveals ESCROW key to Buyer, who
> then clawbacks the payment to the seller.
>   * Escrow judges Seller is right: Escrow deletes ESCROW privkey ("not
> ESCROW"), and the Seller->Buyer payment eventually times out, ending the
> obligation of the Seller.
>
> The "reverse" payment is effectively the inversion of logic by the De
> Morgan theorem, and the "normal case" (buyer ultimately pays seller) has
> the Escrow not revealing the privkey.
> In addition, in the case where Buyer is satisfied (i.e. both Buyer and
> Seller agree the trade is beneficial) the Escrow is never involved (the
> Escrow might have a timeout for the temporary ESCROW keypair, which it will
> eventually delete; since all payments on LN need a timeout anyway, this is
> fine) and thus does not know about the trade, except that some trade was
> requested (since it must provide a temporary ESCROW pubkey).
>
> This even provides a simple BUYER + ESCROW keypair that gives the seller a
> proof-of-refund, and of course the simple SELLER gives the buyer a
> proof-of-payment as well.
> It only just requires twice as much Bitcoins getting locked.
>
> Thoughts?
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Escrow Over Lightning?

[Andrés G . Aragoneses]

Hey ZmnSCPxj,

Am I correct in understanding that this is a proposal to change the spec
(maybe add a new BOLT) so that all lightning implementations can try to
support this feature.

If the above is true, then I'm wondering: could a Lightning-based escrow
system be implemented that doesn't require to modify the existing
implementations? Maybe if we simplify the requirements a bit? Like,
removing the "Escrow only learns of dispute cases, never learns non-dispute
case" aspect? That is, the third-party S always knows about an escrow
between A and B taking place.

I understand that the above requirement is a good to have, but if removing
it allows a simpler version of escrow be implemented, then at least there
could be an interim solution for non-custodial exchanges to start adopting
this (otherwise they have to resort to custodial-based escrows, which is
worse than lacking the escrow privacy brought by the requirement above).

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

Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[Andrés G . Aragoneses]

Hey Antoine, just a small note, [3] is missing in your footnotes, can you
add it? Thanks

On Tue, 5 May 2020 at 18:17, Antoine Riard  wrote:

> Hi,
>
> (cross-posting as it's really both layers concerned)
>
> Ongoing advancement of BIP 157 implementation in Core maybe the
> opportunity to reflect on the future of light client protocols and use this
> knowledge to make better-informed decisions about what kind of
> infrastructure is needed to support mobile clients at large scale.
>
> Trust-minimization of Bitcoin security model has always relied first and
> above on running a full-node. This current paradigm may be shifted by LN
> where fast, affordable, confidential, censorship-resistant payment services
> may attract a lot of adoption without users running a full-node. Assuming a
> user adoption path where a full-node is required to benefit for LN may
> deprive a lot of users, especially those who are already denied a real
> financial infrastructure access. It doesn't mean we shouldn't foster node
> adoption when people are able to do so, and having a LN wallet maybe even a
> first-step to it.
>
> Designing a mobile-first LN experience opens its own gap of challenges
> especially in terms of security and privacy. The problem can be scoped as
> how to build a scalable, secure, private chain access backend for millions
> of LN clients ?
>
> Light client protocols for LN exist (either BIP157 or Electrum are used),
> although their privacy and security guarantees with regards to
> implementation on the client-side may still be an object of concern
> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted fee
> estimation). That said, one of the bottlenecks is likely the number of
> full-nodes being willingly to dedicate resources to serve those clients.
> It's not about _which_ protocol is deployed but more about _incentives_ for
> node operators to dedicate long-term resources to client they have lower
> reasons to care about otherwise.
>
> Even with cheaper, more efficient protocols like BIP 157, you may have a
> huge discrepancy between what is asked and what is offered. Assuming 10M
> light clients [0] each of them consuming ~100MB/month for filters/headers,
> that means you're asking 1PB/month of traffic to the backbone network. If
> you assume 10K public nodes, like today, assuming _all_ of them opt-in to
> signal BIP 157, that's an increase of 100GB/month for each. Which is
> consequent with regards to the estimated cost of 350GB/month for running an
> actual public node. Widening full-node adoption, specially in term of
> geographic distribution means as much as we can to bound its operational
> cost.
>
> Obviously,  deployment of more efficient tx-relay protocol like Erlay will
> free up some resources but it maybe wiser to dedicate them to increase
> health and security of the backbone network like deploying more outbound
> connections.
>
> Unless your light client protocol is so ridiculous cheap to rely on
> niceness of a subset of node operators offering free resources, it won't
> scale. And it's likely you will always have a ratio disequilibrium between
> numbers of clients and numbers of full-node, even worst their growth rate
> won't be the same, first ones are so much easier to setup.
>
> It doesn't mean servicing filters for free won't work for now, numbers of
> BIP157 clients is still pretty low, but what is worrying is  wallet vendors
> building such chain access backend, hitting a bandwidth scalability wall
> few years from now instead of pursuing better solutions. And if this
> happen, maybe suddenly, isn't the quick fix going to be to rely on
> centralized services, so much easier to deploy ?
>
> Of course, it may be brought that actually current full-node operators
> don't get anything back from servicing blocks, transactions, addresses...
> It may be replied that you have an indirect incentive to participate in
> network relay and therefore guarantee censorship-resistance, instead of
> directly connecting to miners. You do have today ways to select your
> resources exposure like pruning, block-only or being private but the wider
> point is the current (non?)-incentives model seems to work for the base
> layer. For light clients data, are node operators going to be satisfied to
> serve this new *class* of traffic en masse ?
>
> This doesn't mean you won't find BIP157 servers, ready to serve you with
> unlimited credit, but it's more likely their intentions maybe not aligned,
> like spying on your transaction broadcast or block fetched. And you do want
> peer diversity to avoid every BIP157 servers being on few ASNs for
> fault-tolerance. Do people expect a scenario a la Cloudflare, where
> everyone connections is to far or less the same set of entities ?
>
> Moreover, the LN security model diverges hugely from basic on-chain
> transactions. Worst-case attack on-chain a malicious light client server
> showing a longest, invalid, PoW-signed chain to double-spend the 

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Andrés G . Aragoneses]

Hey ZmnSCPxj,

On Tue, 21 Jan 2020 at 08:47, ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Good morning Subhra,
>
> Refer to this protocol instead of DLAS:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002035.html
> In this protocol, an *encrypted* form of the *entire file* is sent.
> Consequently, a *single* payment is made, where the payment preimage is
> the decryption key.
> Knowing an additional zk proof is necessary to show that the file is
> indeed encrypted using the decryption key that is the preimage of the given
> hash (the linked thread has details I believe).
>
> Relevantly, there is no need to consider blocks of a file when using the
> linked protocol instead of DLAS.
> Of course, a Zk-proof of some property of the entire file, that can be
> understood by an end-user, may not be possible.
> Likely, you might want to prove of a video file that a thumbnail of the
> video file is extracted from a frame of the video, and show that thumbnail
> to the end-user.
> Looking at the *rest* of the frames of the video (after you have paid for
> its decryption) may very reveal them to be frames of a video of Rick Astley
> singing "Never Gonna Give You Up".
>

I wanted to ask a simple question with regards to the NeverGonnaGiveYouUp
problem.
Let's say you use this technology for a specific use case subset of what
has been proposed: the payer wants to exchange bitcoin (via LN) in exchange
for some data. The data, in this case, was known by the payer at some point
in the past, so the payer encrypted it with his own private key, and gave
it to someone for backup purposes (after that, he gets a hash of the data,
which she keeps, and deletes the data from her end). At some point in the
future, when she wants to retrieve the data, the payee can only supply a
bunch of bytes whose hash match with the hash that the payer has, therefore
the NeverGonnaGiveYouUp problem can't happen here, am I right?

Thanks



> !
>
> Regards,
> ZmnSCPxj
>
> > So is it sufficient to give a zk proof of the entire file and not of the
> individual blocks which are transferred at each iteration? Also does it
> make sense that you make partial payment per block instead of waiting for
> the total file to arrive. It might be the case that the zk proof of the
> total file is correct but then sender might cheat while sending individual
> block.
> >
> > On Tue, Jan 21, 2020, 00:26 Matt Corallo 
> wrote:
> >
> > > Don’t and data in lighting payments unless you have to. It’s super
> DoS-y and rude to your peers. If you’re just transferring a file, you can
> use ZKCP to send an encrypted copy of the file with the encryption key
> being the payment_preimage, making the whole thing one big atomic action.
> > >
> > > > On Jan 20, 2020, at 13:33, Subhra Mazumdar <
> subhra.mazumdar1...@gmail.com> wrote:
> > >
> > > > 
> > > > Sounds good. But how do I provide a correctness for the entire asset
> to be transferred when I am already partitioning into several units (say
> chunks of file ? ) So as an when the block of file is received then we have
> to give a ZK proof "block x is part of File F". Is it how this should work ?
> > > >
> > > > On Mon, Jan 20, 2020 at 11:59 PM Matt Corallo <
> lf-li...@mattcorallo.com> wrote:
> > > >
> > > > > Zk proofs are incredibly fast these days for small-ish programs.
> They’re much too slow for a consensus system where every party needs to
> download and validate them, but for relatively simple programs a two-party
> system using them is very doable.
> > > > >
> > > > > > On Jan 20, 2020, at 13:23, Subhra Mazumdar <
> subhra.mazumdar1...@gmail.com> wrote:
> > > > >
> > > > > > 
> > > > > > But isn't it that the use of ZK proof will render the system
> slow and hence defy the very purpose of lightning network which intends to
> make things scalable as well as faster transaction ?
> > > > > >
> > > > > > On Mon, Jan 20, 2020 at 11:48 PM Matt Corallo <
> lf-li...@mattcorallo.com> wrote:
> > > > > >
> > > > > > > That paper discusses it, but I don't think there was ever a
> paper proper
> > > > > > > on ZKCP. There are various discussions of it, though, if you
> google.
> > > > > > > Sadly this is common in this space - lots of great ideas where
> no one
> > > > > > > ever bothered to write academic-style papers about them (hence
> why
> > > > > > > academic papers around Bitcoin tend to miss nearly all
> relevant context,
> > > > > > > sadly).
> > > > > > >
> > > > > > > Matt
> > > > > > >
> > > > > > > On 1/20/20 6:10 PM, Subhra Mazumdar wrote:
> > > > > > > > Are you referring to the paper Zero knowledge contingent
> payment
> > > > > > > > revisited ? I will look into the construction. Thanks for the
> > > > > > > > information! :)
> > > > > > > >
> > > > > > > > On Mon, Jan 20, 2020, 23:31 Matt Corallo <
> lf-li...@mattcorallo.com
> > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > On 11/9/19 4:31 AM, Takaya Imai