Nostr notes by Andrés G. Aragoneses [ARCHIVE]

📅 Original date posted:2021-10-13 📝 Original message: Hello ...

2023-06-09T13:04:14Z

In reply to nevent1q…gyza
_________________________

📅 Original date posted:2021-10-13
📝 Original message:
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 <lf-lists at mattcorallo.com> 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 an onion message telling you nonce B, forward this
> HTLC, until then, just sit
> on it". The LSP accepts this HTLC but does not forward it and is generally
> okay with the long CLTV
> delta because it would otherwise just be the users' balance anyway - if
> they want to encumber their
> own funds forever, no harm done.
> Note that if tipper is online regularly they can skip this step and
> move on.
>
> Step 3. The Tipper sends an onion message to recipient's LSP saying "hey,
> when recipient is online
> again, use the included reply path to send nonce B to my LSP".
>
> - sender can now safely go offline -
>
> Step 4. When the Recipient comes online, their LSP sends the reply to the
> Tipper's LSP,
>
> Step 5. causing the Tipper's LSP to (finally) forward the original HTLC,
> which the Recipient receives.
>
> You'll note that this solution, unlike simply sending a high-CLTV HTLC,
> does not encumber funds for
> any extended period of time except for the original sender, who wants to
> send the funds off
> elsewhere anyway. Nor does it rely on any parties who can at any point run
> away with the funds (or
> reasonably be construed as custodians for the funds). Further, this
> solution does not rely on the
> sender deanonymizing themselves to the recipient (or even informing the
> recipient who the senders'
> LSP is).
>
> Note that lnurl here could be replaced with BOLT 12 if BOLT 12 gets some
> flag indicating the Tipper
> should ask an LSP for the invoice.
>
> But, okay, so the lnurl model of a trusted party not reusing invoices so
> that the Recipient's LSP
> cannot just steal all funds after the first claim kinda really sucks, how
> do we do better?
>
> The Obvious (tm) solution here is PTLCs - just have the sender always add
> some random nonce * G to
> the PTLC they're paying and send the recipient a random nonce in the
> onion. I'd generally suggest we
> just go ahead and do this for every PTLC payment, cause why not? Now the
> sender and the lnurl
> endpoint have to collude to steal the funds, but, like, the sender could
> always just give the lnurl
> endpoint the money. I'd love suggestions for fixing this short of PTLCs,
> but its not immediately
> obvious to me that this is possible.
>
> Thanks to Steve for pushing on the "how does a let users get tips in
> lightning" issue, various
> people for giving him feedback and the relayed to me, AJ for the PTLC
> proposal, and Rusty for
> tireless drum-beating on onion messages and BOLT 12.
>
> Matt
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211013/d180dac7/attachment.html>;

📅 Original date posted:2021-10-11 📝 Original message: ...

2023-06-09T13:04:02Z

In reply to nevent1q…4d2a
_________________________

📅 Original date posted:2021-10-11
📝 Original message:
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 <fabrice.drouin at acinq.fr> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211011/6d0c920c/attachment.html>;

📅 Original date posted:2021-08-23 📝 Original message: How ...

2023-06-09T13:03:24Z

In reply to nevent1q…shth
_________________________

📅 Original date posted:2021-08-23
📝 Original message:
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 <carnhofdaki at gmail.com> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210823/2db7b37d/attachment.html>;

📅 Original date posted:2021-02-11 📝 Original message: Hey ...

2023-06-09T13:02:00Z

In reply to nevent1q…slaf
_________________________

📅 Original date posted:2021-02-11
📝 Original message:
Hey ZmnSCPxj,

On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj <ZmnSCPxj at protonmail.com> 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 <ZmnSCPxj at protonmail.com> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210211/ad341e90/attachment-0001.html>;

📅 Original date posted:2021-02-13 📝 Original message: Hey ...

2023-06-09T13:02:00Z

In reply to nevent1q…vccd
_________________________

📅 Original date posted:2021-02-13
📝 Original message:
Hey ZmnSCPxj,

On Fri, 12 Feb 2021 at 08:52, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Andres,
>
> > Hey ZmnSCPxj,
> >
> > On Thu, 11 Feb 2021 at 15:33, ZmnSCPxj <ZmnSCPxj at protonmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210213/ff3292bc/attachment.html>;

📅 Original date posted:2021-02-11 📝 Original message: This ...

2023-06-09T13:01:59Z

In reply to nevent1q…rwqy
_________________________

📅 Original date posted:2021-02-11
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210211/c6a316f0/attachment.html>;

📅 Original date posted:2021-02-08 📝 Original message: Hey ...

2023-06-09T13:01:57Z

In reply to nevent1q…6pet
_________________________

📅 Original date posted:2021-02-08
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210208/7070bbe6/attachment.html>;

📅 Original date posted:2020-11-27 📝 Original message: Hey, ...

2023-06-09T13:01:34Z

In reply to nevent1q…utzn
_________________________

📅 Original date posted:2020-11-27
📝 Original message:
Hey,

On Fri, 27 Nov 2020 at 19:18, Bastien TEINTURIER <bastien at acinq.fr> wrote:

> Good morning list,
>
> This is an interesting approach to solve this problem, I really like the
> idea.
> It definitely deserves digging more into it: the fact that it doesn't add
> an additional
> payment makes it largely superior to upfront payment schemes in terms of
> UX.
>
> If we restrict these stake certificates to LN funding txs, which have a
> very specific format
> (multisig 2-of-2) there are probably smart ways to achieve this.
> If for example we're able to do it easily with Schnorr-based funding txs,
> it may be worth
> waiting for that to happen.
> I'm a bit afraid of having to use ZKPs for general statements, I'd prefer
> something tailored
> to that specific case (it would likely be more efficient and have less new
> assumptions - even
> though you're right to point out that this is a non-critical system, so
> we're freer to experiment
> with hot new stuff).
>
> I completely agree with Z that it should be added to the requirements that
> a node cannot
> reuse a stake certificate from another node for himself.
>
> Another constraint is that the proof has to be small, since we have to fit
>> it all in a small onion...
>>
>
> I'm not sure that's necessary. If I understand correctly, you're saying
> that because in your
> model, the sender (Alice) creates one stake certificate for each node in
> the route (Bob, Carol)
> and puts them in the onion.
>
> But instead it could be a point-to-point property: each node provides its
> own stake certificate
> to the next node (and only to that node). Alice provides a stake
> certificate to Bob, then Bob
> provides a stake certificate to Carol, and so on. If that's the case, it
> can be in a tlv field in the
> `update_add_htlc` message and doesn't need to be inside the onion. This
> also makes it less
> likely that Alice is exposing herself to remote nodes in the route (payer
> privacy).
>

If the above paragraph is confirmed, then does this mean StakeCertificates
with privacy are possible without ZK proofs?
Or did I miss something?

>
> Of course, this depends on the implementation details we choose, but I
> think it's worth stressing
> that these two models exist and are quite different.
>
> Thanks,
> Bastien
>
> Le ven. 27 nov. 2020 à 07:46, ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> a écrit :
>
>> Good morning Gleb,
>>
>> > Thank you for your interest :)
>> >
>> > > Quick question: if I am a routing node and receive a valid stake
>> certificate, can I reuse this stake certificate on my own outgoing payments?
>> >
>> > That probably should be avoided, otherwise a mediocre routing node gets
>> a lot of jamming opportunities for no good.
>> >
>> > You are right, that’s a strong argument for proof “interactivity”:
>> every Certificate should probably commit to *at least* public key of the
>> routing node it is generated for.
>>
>> Right, it would be better to have the certificate commit to a specific
>> routing node rather than the payment hash/point as I proposed.
>> Committing to a payment hash/point allows a random forwarding node to
>> probe the rest of the network using the same certificate, lowering the
>> score for that certificate on much of the network.
>>
>> Another constraint is that the proof has to be small, since we have to
>> fit it all in a small onion...
>>
>> Presumably we also want the score to eventually "settle to 0" over time.
>>
>> Regards,
>> ZmnSCPxj
>>
>> >
>> > – gleb
>> > On Nov 27, 2020, 2:16 AM +0200, ZmnSCPxj <ZmnSCPxj at protonmail.com>,
>> wrote:
>> >
>> > > Good morning Gleb and Antoine,
>> > >
>> > > This is certainly interesting!
>> > >
>> > > Quick question: if I am a routing node and receive a valid stake
>> certificate, can I reuse this stake certificate on my own outgoing payments?
>> > >
>> > > It seems to me that the proof-of-stake-certificate should also
>> somehow integrate a detail of the current payment (such as payment
>> hash/point) so it cannot be reused by routing nodes for their own outgoing
>> payments.
>> > >
>> > > For example, looking only at your naive privacy-broken proposal, the
>> signature must use a `sign-to-contract` where the `R` in the signature is
>> actually `R' + h(R' | payment_hash)` with the `R'` also revealed.
>> > >
>> > > Regards,
>> > > ZmnSCPxj
>> > >
>> > > > Hello list,
>> > > >
>> > > > In this post, we explore a different approach to channel jamming
>> mitigation.
>> > > > We won’t talk about the background here, for the problem
>> description as well as some proposed solutions (mainly upfront payment
>> schemes), see [1].
>> > > >
>> > > > We’re suggesting using UTXO ownership proofs (a.k.a. Stake
>> Certificates) to solve this problem. Previously, these proofs were only
>> used in the Lightning Network at channel announcement time to prevent
>> malicious actors from announcing channels they don’t control. One can think
>> of it as a “fidelity bond” (as a scarce resource) as a requirement for
>> sending HTLCs.
>> > > >
>> > > > We start by overviewing issues with other solutions, and then
>> present a naive, privacy-broken Stake Certificates. Then we examine
>> designing a privacy-preserving version, evaluating them. At the end, we
>> talk about non-trivial design decisions and open questions.
>> > > >
>> > > > ## Issues with other proposals
>> > > >
>> > > > We find unsatisfying that upfront payment schemes come at a cost of
>> new fees (forward and/or backward), thus inflating payment cost for *any*
>> payment.
>> > > > In the future, the upfront base fee might even make “micropayments”
>> economically infeasible by exceeding the value they transfer. Thus, a good
>> solution should not inflate payment cost while still requiring “burning” a
>> scarce resource (so that the attack is not free).
>> > > >
>> > > > Another issue with upfront payments is a circular trust dependency.
>> Ideally, we shouldn’t introduce anything less trust-minimized than the
>> Lightning Network itself.
>> > > > Upfront payment schemes are not like that, because they in one way
>> or another rely on the honest behavior of route participants.
>> > > >
>> > > > We believe Stake Certificates we are going to introduce are
>> satisfactory in both of these directions: they don’t inflate payment costs
>> for honest users and don’t require trust. The main disadvantage of Stake
>> Certificates seems to be the novel cryptography required.
>> > > > See more details in the “Evaluation” section.
>> > > >
>> > > > ## Channel Ownership Proofs as Routing Credit Balance
>> > > >
>> > > > Let’s say Alice wants to relay an HTLC to Carol through Bob. Per
>> the Stake Certificates scheme, she has to commit to a particular channel
>> UTXO by embedding an ownership proof in the onion packet while sending an
>> HTLC to Bob.
>> > > >
>> > > > Bob then unwraps the onion and verifies:
>> > > > 1) the channel identifier is pointing unambiguously to an on-chain
>> UTXO;
>> > > > 2) the ownership proof (e.g., a signature) is valid against the
>> previously disclosed UTXO witness script.
>> > > >
>> > > > If all those checks succeed, Bob should see if Alice hasn’t
>> exceeded her credit balance. In case she hasn’t, Bob has to “decrement
>> Alice’s credit balance” and relay the HTLC to Carol.
>> > > > Decrementing credit balance unconditionally of packet success or
>> failure bounds liquidity abuse by malicious HTLC senders.
>> > > > Since there is no credit assigned initially, “decrementing the
>> credit balance” means just remembering that “Alice spent X out of Y of the
>> credit she received for her Stake Certificates”.
>> > > >
>> > > > Unfortunately, this naive protocol is a privacy nightmare, because
>> routing nodes can now easily assign every HTLC they forward to the sender’s
>> UTXO.
>> > > >
>> > > > Let’s first define the terms here one more time, and then proceed
>> to the non-naive, private Stake Certificates.
>> > > >
>> > > > - Stake Certificate. Either means a solution we’re proposing or the
>> primitive it is based on, namely proof of UTXO ownership. As we will argue
>> later, it actually makes sense to use proof of LN channel UTXO ownership
>> specifically rather than any funds ownership.
>> > > > - Stake Certificate value. An amount of the corresponding UTXO or a
>> ballpark this amount provably belongs to.
>> > > > - Credit balance. When Alice provides a routing node Bob with a
>> Stake Certificate, Bob should increase Alice’s routing credit balance.
>> Alice is then limited in her payments by this balance, and this rule is
>> enforced by routing nodes to prevent free channel jamming in the network.
>> Note that ideally “Alice’s credit balance“ should be virtual and only known
>> to Alice, while routing nodes should only observe per-UTXO credit balance.
>> We currently assume that each routing node keeps track of per-UTXO credit
>> balance separately, see “Design decisions” for more details.
>> > > > - Stake-to-credit function defines how much credit balance is given
>> per a Stake Certificate of a given value. This function is a policy of a
>> routing node, and it should be announced.
>> > > > - Credit-to-value-transferred function defines how much value a
>> sender can transfer along a given channel considering how much credit they
>> might claim. The function may also consider different factors (e.g., the
>> available capacity of a channel being used) to provide extra robustness.
>> > > >
>> > > > ## Privacy-preserving Stake Certificates
>> > > >
>> > > > The presented scheme could preserve privacy if it relied on
>> zero-knowledge proofs of UTXO ownership by avoiding pointing to a
>> particular UTXO.
>> > > > More specifically, the verifier should be able to check that:
>> > > > a) The staked UTXO is an element of the current UTXO set
>> > > > b) The prover knows the witness script committed by the UTXO
>> witness program
>> > > > c) The prover knows a valid witness for the witness script
>> > > > d) The staked UTXO was not used to produce a different Stake
>> Certificate which is currently in use as well.
>> > > >
>> > > > The verifier should also have a way to see a Stake Certificate
>> value to properly account for the credit. This can be achieved by
>> restricting the UTXO set being proved upon to only those UTXOs with a
>> specific range of values: “I will prove that I own a UTXO among all UTXOs
>> between 0.5 BTC and 1 BTC”.
>> > > >
>> > > > Unfortunately, steps (b) and (c) require zero-knowledge protocols
>> for general statements, which are more experimental primitives than most of
>> the stuff we have in Bitcoin protocols,
>> > > > although we assume it’s feasible to consider them for non-consensus
>> stuff.
>> > > >
>> > > > ## Evaluation
>> > > >
>> > > > Stake Certificates, upfront payment schemes, and other potential
>> solutions (given a particular configuration) may be compared along the
>> following axis:
>> > > > 1) Economic feasibility
>> > > > 1a) What is the cost of overcoming the protection for an attacker?
>> Likely a non-linear function: sats_spent =f(channels_to_jam, […])
>> > > > 1b) How does this solution limit honest users?
>> > > > 2) How sophisticated is this solution in terms of integration and
>> making good UX?
>> > > > 3) How complex is this solution in terms of protocol
>> design/implementation?
>> > > >
>> > > > When it comes to (1a), both Stake Certificates and upfront payments
>> are probably equal, in a way that they’re just best-effort ideas to
>> increase the attack cost. Unfortunately, we currently don’t know how to
>> design something as economically powerful as PoW in Bitcoin [3].
>> > > > This aspect can be properly evaluated by applying these ideas to
>> different hypothetical kinds of LN in a simulation and observing the
>> resulting trade-off between (1a) and (1b) considering different attack
>> strategies.
>> > > >
>> > > > In the previous sections of this post, we have argued that Stake
>> Certificates may provide a much better (1b) for the cost of (3) because it
>> relies on zero-knowledge.
>> > > > When it comes to (2), the design of Stake Certificates may vary in
>> terms of UX burden, from completely automatic to requiring custom actions
>> with private keys from users.
>> > > >
>> > > > Some of these trade-offs along with other interesting questions are
>> discussed in the following section.
>> > > >
>> > > > ## Design decisions and questions
>> > > >
>> > > > #### Should the credit spending be gossipped across the entire
>> network, or should only the routing nodes involved in the payment know?
>> > > >
>> > > > Economically, these two approaches are likely to be equivalent, and
>> it’s just a matter of stake-to-credit ratio.
>> > > > However, announcing credit spending to the network results in a
>> privacy leak. It also imposes bandwidth and CPU overhead on the routing
>> nodes.
>> > > >
>> > > > #### Which zero-knowledge system should be used for Stake
>> Certificates?
>> > > >
>> > > > Choosing a ZK system boils down to picking the right trade-offs of
>> proving and verifying time, and assumptions. As we mentioned previously, we
>> would need proving general statements.
>> > > > At the same time, we need something cheap in both proving and
>> verification, because Lightning is supposed to be fast.
>> > > > At the same time, the setup probably doesn’t matter, because proofs
>> are supposed to be verified only by one participant, a routing node this
>> proof is generated for.
>> > > > Perhaps we can also pick any cryptographic assumptions we want
>> since this stuff is not mission-critical and can be easily updated if
>> someone breaks a cryptographic assumption and we observe an attack.
>> > > >
>> > > > #### Should we allow holding *any* Bitcoins (not just LN channels)
>> for Stake Certificates?
>> > > >
>> > > > This idea might make sense if we’re worried that some LN users
>> might want to send more payments than they can afford per their credit.
>> However, we believe that allowing any UTXO would give an attacker more
>> opportunities to use their cold funds for this attack, or even have a
>> secondary market where holders sell their proofs (they have nothing to
>> loose).
>> > > > Instead, we should a) design the credit-to-stake-functions better;
>> b) encourage users send payments across different routing nodes (since
>> credits are not tracked globally) [4].
>> > > >
>> > > > #### What’s the best credit-to-value-transferred function?
>> > > >
>> > > > We reckon that this function should be not just linear to provide
>> maximum security against malicious channel jammers. For example, we can
>> charge more credit for the last 20% of the capacity of the *channel used
>> for routing*. Alternatively, we could discourage making too many payments
>> from the same UTXO within a short period of time by charging more credit in
>> this case.
>> > > >
>> > > > #### What about the interactivity and lifetime of Stake
>> Certificates?
>> > > >
>> > > > Interactive proofs mean that they are constructed on demand of a
>> routing node, non-interactive means constructed by a payment sender ahead
>> of time.
>> > > > Both interactivity and lifetime have something to do with the ease
>> of producing proof and accessing keys.
>> > > > We will omit the details of the trade-off we consider, but it
>> remains an open question.
>> > > >
>> > > > #### If Stake Certificates are valid for N blocks after proof
>> generation, does it mean that if the UTXO is spent during those N blocks,
>> new proof can be generated from the same coins without invalidating the old
>> proof?
>> > > >
>> > > > Yes, but an attacker would, first of all, have to pay an on-chain
>> fee for this. If we’re still worried about this problem, there are
>> workaround ideas.
>> > > > For example, we could have epochs of 100 blocks (every epoch starts
>> at #XYZXYZ00 block). If at the start of an epoch, a channel wasn’t in the
>> UTXO set, it provides very little credit.
>> > > > Alternatively, we could expand the zero-knowledge part to proving
>> that the coins were not yet spent.
>> > > >
>> > > > #### Should spending a UTXO reveal all Stake Certificates generated
>> from it?
>> > > >
>> > > > This would also solve the problem in the previous question, but it
>> would mean a retrospective privacy leak again. To avoid a privacy leak, we
>> should prevent this.
>> > > >
>> > > > #### What if malicious Sybil *routing* nodes failing payments
>> causing other honest routing nodes to reduce the credit of an honest
>> payment sender?
>> > > >
>> > > > Both Stake Certificates and upfront payment schemes suffer from
>> malicious routing nodes failing the payments and “wasting” the sender’s
>> credit or fees. This problem even applies out of the channel jamming
>> context, when considering payment failure rate.
>> > > > This problem can be addressed by reducing the reputation of faulty
>> links and routing nodes on the payment sender node. When payment routing
>> becomes a for-profit activity, this would encourage routing nodes to
>> sanitize their links.
>> > > > The mitigation can be even stronger by using “provable blaming”
>> introduced in [2].
>> > > >
>> > > > ## Conclusion
>> > > >
>> > > > We propose Stake Certificates, a new solution to channel jamming.
>> Perhaps, it might not be the best near-term solution due to the complexity,
>> but the zero satoshi overhead for honest payments is an appealing argument
>> to switch to it in the future.
>> > > > This proposal also illustrates how stake-based protocols can solve
>> Sybil challenges in the Bitcoin ecosystem. Since this might be useful in
>> other contexts (Sybil-resistance of many kinds, proof-of-ownership),
>> discussing Stake Certificates is even more useful.
>> > > > The next step is a discussion of Stake Certificates. If the
>> community finds it interesting, then we should discuss the design questions
>> mentioned above, and choose a cryptosystem.
>> > > >
>> > > > Cheers,
>> > > > Gleb Naumenko and Antoine Riard
>> > > >
>> > > > ———
>> > > >
>> > > > References and footnotes:
>> > > > 1.
>> https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md
>> > > > 2.
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
>> > > > 3. We don’t actually suggest PoW to solve these issues, because a)
>> the trade-off between honest user cost and attacker cost is misaligned due
>> to specialized hardware and b) smartphones would die too fast if they have
>> to compute PoW; PoW is just an unreachable example of system robustness due
>> to well-aligned game theory.
>> > > > 4. Secondary markets are still possible even if we restrict
>> acceptable proofs to only LN channels, but supply would be much smaller,
>> and markets would work much worse for an attacker.
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201127/ca1ded55/attachment-0001.html>;

📅 Original date posted:2020-05-05 📝 Original message: Hey ...

2023-06-09T13:00:00Z

In reply to nevent1q…vwfu
_________________________

📅 Original date posted:2020-05-05
📝 Original message:
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 <antoine.riard at gmail.com> 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 user. On
> LN, the *liveliness* requirement means the entity owning your view of the
> chain can lie to you on whether your channel has been spent by a revoked
> commitment, the real tip of the blockchain or even dry-up block
> announcement to trigger unexpected behavior in the client logic. A
> malicious light client server may just drop any filters/utxos spends, what
> your LN client should do in this case ? [1]
>
> Therefore, you may want to introduce monetary compensation in exchange of
> servicing filters. Light client not dedicating resources to maintain the
> network but free-riding on it, you may use their micro-payment capabilities
> to price chain access resources [3]. This proposition may suit within the
> watchtower paradigm, where another entity is delegated some part of
> protocol execution, alleviating client onliness requirement. It needs
> further analysis but how your funds may be compromised by a watchtower are
> likely to be the same scenario that how a chain validation provider can
> compromise you. That said, how do you avoid such "chain access" market
> turning as an oligopoly is an open question. You may "bind" them to
> internet topology or ask for fidelity bonds and create some kind of
> scarcity but still...
>
> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
> just rely on few thousands of full-node operators being nice and servicing
> friendly millions of LN mobiles clients. But just in case it may be good to
> consider a reasonable alternative.
>
> Thanks Gleb for many points exposed here but all mistakes are my own.
>
> Cheers,
>
> Antoine
>
> [0] UTXO set size may be a bottleneck, but still if you have 2 channels by
> clients that's 20M utxos, just roughly ~x3 than today.
>
> [1] And committing filters as part of headers may not solve everything as
> an attacker can just delay or slow announcements to you, so you still need
> network access to at least one honest node.
>
> [2] It maybe argue that distinction client-vs-peer doesn't hold because
> you may start as a client and start synchronizing the chain, relaying
> blocks, etc. AFAIK, there is no such hybrid implementation and that's not
> what you want to run in a mobile.
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200505/15b6aaac/attachment-0001.html>;

📅 Original date posted:2020-01-21 📝 Original message: Hey ...

2023-06-09T12:58:09Z

In reply to nevent1q…fp9c
_________________________

📅 Original date posted:2020-01-21
📝 Original message:
Hey ZmnSCPxj,

On Tue, 21 Jan 2020 at 08:47, ZmnSCPxj via Lightning-dev <
lightning-dev at 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 <lf-lists at mattcorallo.com>
> 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.mazumdar1993 at 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-lists at 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.mazumdar1993 at 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-lists at 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-lists at mattcorallo.com
> > > > > > > > <mailto:lf-lists at mattcorallo.com>> wrote:
> > > > > > > >
> > > > > > > > On 11/9/19 4:31 AM, Takaya Imai wrote:
> > > > > > > > > [What I do not describe]
> > > > > > > > > * A way to detect that data is correct or not, namely
> zero knowledge
> > > > > > > > > proof process.
> > > > > > > >
> > > > > > > > Have you come across Zero Knowledge Contingent Payments?
> Originally it
> > > > > > > > was designed for on-chain applications but it slots
> neatly into
> > > > > > > > lightning as it only requires a method to lock funds to
> a hash preimage.
> > > > > > > >
> > > > > > > > Matt
> > > > > > > > _______________________________________________
> > > > > > > > Lightning-dev mailing list
> > > > > > > > Lightning-dev at lists.linuxfoundation.org
> > > > > > > > <mailto:Lightning-dev at lists.linuxfoundation.org>
> > > > > > > >
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > Yours sincerely,
> > > > > > Subhra Mazumdar.
> > > >
> > > > --
> > > > Yours sincerely,
> > > > Subhra Mazumdar.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200121/b6c831d6/attachment.html>;

📅 Original date posted:2017-01-16 📝 Original message: On 16 ...

2023-06-09T12:46:58Z

In reply to nevent1q…te2g
_________________________

📅 Original date posted:2017-01-16
📝 Original message:
On 16 January 2017 at 15:32, Anthony Towns <aj at erisian.com.au> wrote:

> On Mon, Jan 16, 2017 at 02:44:43PM +0800, Andrés G. Aragoneses wrote:
> > But I thought this problem was already solved by using OP_CLTV/OP_CSV
> -style
> > channels instead of Spillman-style ones?
> > See:
> > http://bitcoin.stackexchange.com/a/48546/2751
>
> The approach described there is to have a channel timeout (adding the
> "customer signs, but locktime greater than refund time" alternative to
> the P2SH address). The lightning spec doesn't currently do that (see the
> "Funding Transaction Output" section of [0]). Lightning uses CLTV and CSV
> to make the HTLC steps work, that is to make the channel bidirectional,
> rather than being limited to having one end take the role of customer
> sending money to the merchant on the other end.
>

Ok but I also read the last paragraph of the last version of the Lightning
paper which I quote:

"A further stop-gap solution using OP CHECKSEQUENCEVERIFY
57or a less-optimal use of OP CHECKLOCKTIMEVERIFY will be described
in a future paper by Rusty Russell. An updated version of this paper will
also include these constructions."

So I guess I was confused by thinking that Lightning Level1 and Level2 was
referring to this, and maybe someone forgot to update the paper to include
L1&L2.

But no, we're talking about using CLTV (or CSV, I guess?) for the refund
transaction instead of for the HTLC. Would we be able to call this an
hypothetical Level2.5 of LN? (Level 3 being the one requiring SeqWit).

>
> [0] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-
> transactions.md
>
> It's not a 100% solution on its own though -- the "merchant" in this
> scenario can choose not to provide the second signature back to the
> customer ever, in which case the customer can't access their funds
> again until the refund time arrives. Better than being never able to
> access their funds again, of course, which is what you get if you use
> the current method, without segwit, and get malleated.
>

Exactly, that's why I think L2.5 would be the only feasible solution in
lack of L3.

>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170116/44b73efd/attachment.html>;

📅 Original date posted:2017-01-16 📝 Original message: On 16 ...

2023-06-09T12:46:58Z

In reply to nevent1q…qyfv
_________________________

📅 Original date posted:2017-01-16
📝 Original message:
On 16 January 2017 at 14:31, Anthony Towns <aj at erisian.com.au> wrote:

> On Mon, Jan 16, 2017 at 01:00:48PM +1030, Rusty Russell wrote:
> > > Which one is more accurate? Is the security problems only related to
> having
> > > to watch the blockchain? If yes, why cannot one outsource this job to a
> > > server (e.g. the hypothetical server of your light-wallet) in level2?
> > Yes, the problem is outsourcing.
>
> I thought the big problem was setup; you can't setup a new channel with a
> stranger on the internet if they can coordinate with a miner to prevent
> you from being able to reclaim your funds. (I didn't think outsourcing
> was anywhere near ready, let alone already being blocked by miners :)
>
> I have an idea on that though, I think... The idea when we were looking at
> BIP 62 as a solution (which would have still left signature malleability
> as a problem) was to have only one side pay into the funding transaction,
> so that the other side couldn't malleate it and prevent the inital
> refund. ie:
>
> - Alice pays $X into an output redeemable by 2-of-2 multisig, Alice and
> Bob,
> signs it, works out the txid, but doesn't publish yet.
> - Alice asks Bob to sign a refund tx that spends that transaction giving
> $X
> back to Alice, with the usual HTLC behaviour so that it becomes unusable
> once the channel starts being used.
> - Once Bob does this and Alice is satisfied, Alice publishes the original
> $X tx and once it is in the blockchain the channel is open.
>
> The problem is that if any third party malleability is possible, and
> happens to Alice's original tx, then Bob's signature on the refund tx is
> no longer useful, and unless Bob is kind enough to sign a new refund tx,
> Alice has lost her money.
>
> Given there's no cost to Bob doing this, and potentially some profit if
> Bob can convince Alice to pay a 10% fee to get her money back (or even
> just the joy of vandalism if you're a troll or hate the idea of lightning
> or whatever), there could be lots of people filling the role of "Bob"
> and it could be hard to find someone safe to open a channel with, and,
> in effect, lightning isn't usable at all except with people you already
> know and trust, which isn't very decentralised.
>

But I thought this problem was already solved by using OP_CLTV/OP_CSV
-style channels instead of Spillman-style ones?

See:
http://bitcoin.stackexchange.com/a/48546/2751
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170116/ac47140c/attachment-0001.html>;

📅 Original date posted:2017-01-16 📝 Original message: On 16 ...

2023-06-09T12:46:57Z

In reply to nevent1q…2j9n
_________________________

📅 Original date posted:2017-01-16
📝 Original message:
On 16 January 2017 at 10:30, Rusty Russell <rusty at rustcorp.com.au> wrote:

> "Andrés G. Aragoneses " <knocte at gmail.com> writes:
> > Hi there,
> >
> > Seems like the list is a bit dormant these days.
>
> Yes, most of the activity has been on the github repository:
>
> https://github.com/lightningnetwork/lightning-rfc
>
>
That's good! I will ask some question about that, bu in a different
thread...

> > Is it because of the low chances of SegWit activation given that it
> stalled
> > at ~26%?
> >
> > On this topic, I would like to ask about the feasibility of LN without
> > SegWit, given these circumstances.
> >
> > Some has been said in the past, I've been reading through the archives.
> But
> > in them, everybody seemed overly enthusiastic about the activation of
> > SegWit (maybe given that OP_CLTV and OP_CSV activated without hassle).
>
> If segwit doesn't activate, something is badly broken in Bitcoin. This
> is not really a lightning issue; there's been no significant technical
> objection to segwit, and it really does make Bitcoin work better.
>

True.

But I guess we're learning that it can happen that technical improvements
get non-technical impediments. In this case, my rough guess is that miners
are afraid of losing their fee-gathering monopoly for moving money to
layer2-actors (payment hubs), given that it will be much easier to spawn
paymenthub nodes than mining nodes.

Given this, IMHO the only way to move forward would be to start running
layer2 solutions in production in spite of the technical difficulties that
SegWit non-activation implies. Then, when miners realize they cannot halt
progress on layer2 development, they will probably start assuming they need
to give up blocking, for the sake of not stagnating the currency (which
would lead to the rise of usage of other chains I suppose).

>
> I'm glad that miners are cautious with their upgrades, and segwit
> adoption will take time to roll out across products anyway. Let's look
> again in 6 months.
>
> > Which one is more accurate? Is the security problems only related to
> having
> > to watch the blockchain? If yes, why cannot one outsource this job to a
> > server (e.g. the hypothetical server of your light-wallet) in level2?
>
> Yes, the problem is outsourcing. You can't hand the outsourcer a
> penalty transaction signature if you don't know what the bad transaction
> will look like. And if the signatures are part of the transaction ID,
> you don't.
>

Can you elaborate on this? From my limited understanding, I guess you're
referring to detecting a broadcast of a transaction of a previous state of
the payment channel. In this case, the HTLC-clock of the revocation
transaction starts ticking, and the transaction to revoke this malicious
move would need the ID of the transaction used to broadcast the bad state.
Right?

If my assumption was correct, wouldn't it be possible to have an
alternative Lightning-Level2? That is: without SegWit, but still with CSV.
And, instead of using revocation, use shorter locktimes like the
Spillman-style payment channels do (everytime there's a need to change
direction)? I know that Spillman-style channels use nLockTime, which is
vulnerable to malleability; so my question is: is there a way to create
OP_CLTV/OP_CSV-style channels (instead of nLockTime-based, so malleability
resistant) without using revocation methods?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170116/13603bc4/attachment.html>;

📅 Original date posted:2017-01-14 📝 Original message: Hi ...

2023-06-09T12:46:56Z

In reply to nevent1q…zr43
_________________________

📅 Original date posted:2017-01-14
📝 Original message:
Hi there,

Seems like the list is a bit dormant these days.

Is it because of the low chances of SegWit activation given that it stalled
at ~26%?

On this topic, I would like to ask about the feasibility of LN without
SegWit, given these circumstances.

Some has been said in the past, I've been reading through the archives. But
in them, everybody seemed overly enthusiastic about the activation of
SegWit (maybe given that OP_CLTV and OP_CSV activated without hassle).

I also stumbled across some notes about a talk on this topic ("BIPs
necessary for lightning"):
https://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning/
In it, the 3-levels of LN are explained, level 1 with OP_CLTV, level 2 with
OP_CVS and level 3 with SegWit+SigHash new opcodes.

That link, the level I'm interested in (2), seems to only highlight about
how inefficient would be compared to level3. However, Joseph Poon has been
quoted also mentioning "security" problems involved in level2 vs level3:
http://www.bitcoinisle.com/2016/11/12/whats-left-before-bitcoins-lightning-network-goes-live/:

"...while aspects of Lightning are possible without the fix, the technology
would be far less secure without it"

This contrasts to what is said in this other article:
https://bitcoinmagazine.com/articles/lightning-network-one-step-closer-to-reality-as-lightning-labs-announces-alpha-release-1484333955
:

"[level3] would allow users to outsource channel monitoring, which means
they won’t have to constantly keep an eye on the Bitcoin blockchain.
Meanwhile channels could be kept open longer and closed quicker. It would
offer a better user experience overall”.

Which one is more accurate? Is the security problems only related to having
to watch the blockchain? If yes, why cannot one outsource this job to a
server (e.g. the hypothetical server of your light-wallet) in level2?

Thanks in advance for any clarifications,

Andres
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170114/37e0e421/attachment.html>;

📅 Original date posted:2021-08-23 📝 Original message: How ...

2023-06-09T12:40:54Z

In reply to nevent1q…gq8e
_________________________

📅 Original date posted:2021-08-23
📝 Original message:
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 <carnhofdaki at gmail.com> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210823/2db7b37d/attachment.html>;