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

[Matt Corallo]

On 10/12/21 22:08, Andrés G. Aragoneses wrote:

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.


Yes, but not just locked, just "doesn't have the lightning app open and in the foreground when a 
payment comes in".  See this paragraph:



     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 :).

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

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 

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

[Matt Corallo]

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 

Re: [Lightning-dev] Lightning over taproot with PTLCs

[Lloyd Fournier]

On Tue, 12 Oct 2021 at 14:08, Anthony Towns  wrote:

>
> If you're willing to accept that "worst case" happening more often, I
> think you could then retain the low latency forwarding, by having the
> transaction structure be:
>
> commitment tx
>   input:
>  funding tx
>   outputs:
>  Alice's balance
>  (others)
>
> low-latency inflight tx:
>   input:
> Alice's balance
>   output:
> (1) or (2)
> Alice's remaining balance
>
> Bob claim:
>   input:
> (1) [ CSV bob CHECKSIG]
>   output:
> [ checksigverify  checksig
>  ifdup notif  csv endif]
>
> Too-slow:
>   input:
> (2) [ CLTV alice CHECKSIG]
>   output:
> Alice
>
> The idea being:
>
>  * Alice sends the low-latency inflight tx which Bob then forwards
>immediately.
>
>  * Bob then tries to update the base channel state with Alice, so both
>sides have a commitment to the new payment, and the low-latency
>inflight tx is voided (since it's based on a revoked channel state)
>If this succeeds, everything is fine as usual.
>
>  * If Alice is unavailable to confirm that update, Bob closes the
>channel prior to (payment-timeout - payment-recover-delay), and posts
>"Bob claim". After an additional pyment recovery delay (and prior
>to payment-timeout) Bob posts Bob claim, ensuring that the only way
>Alice can claim the funds is if he had posted a revoked state.
>
>  * In this case, Alice has at least one payment-recovery-delay period
>prior to the payment-timeout to notice the transaction onchain and
>recover the preimage.
>
>  * If Bob posted the low-latency inflight tx later than
>(payment-timeout - payment-recovery-delay) then Alice will have
>payment-recovery-delay time to notice and post the "too-slow" tx and
>claim the funds via the timeout path.
>
>  * If Bob posted a revoked state, Alice can also claim the funds via
>Bob claim, provided she notices within the channel-recovery-delay
>

In my mind your "update the base channel state" idea seems to fix
everything by itself. So at T - to_self_delay (or a bit before) you say to
your counterparty "can we lift this HTLC out of your in-flight tx into the
'balance tx' (which will go back to naming a 'commitment tx' since it
doesn't just have balance outputs anymore) so I can use it too? --
otherwise I'll have to close the channel on chain now to force you to
reveal it to me on time?". If they agree, after the revocation and new
commit tx everything is back to (tx symmetric) Poon-Dryja so no need for
extra CSVs. Am I missing something?

I realise this kills some of the elegance of your original protocol and
adds quite a bit of complexity but I think it retains the important
properties.


> That only allows one low-latency payment to be inflight though, which I'm
> not sure is that interesting... It's also kinda complicated, and doesn't
> cover both the low-latency and offline cases, which is disappointing...
>
>
It seems to me lazily lifting the HTLCs into the commitment tx would allow
as many low-latency payments as you want to be in-flight. You would
probably just lift them all up to the commitment tx if you lift one. I
think in the case of nodes that want to keep channel keys offline, having
to go on-chain at T - to_self_delay is not a disaster since it will likely
only be the payment receiver who has their keys offline i.e. the merchant
or end user. So only the last hop would go on chain if the user fails to
claim payment as per usual (just to_self_delay earlier than usual).

Cheers,

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

Re: [Lightning-dev] Issue assets on lightning

[ZmnSCPxj via Lightning-dev]

Good morning Prayank,

> Hello everyone,
>
> I wanted to know few things related to asset issuance on lightning:
>
> 1.Is it possible to issue assets on LN right now? If yes, what's the process 
> and is it as easy as few commands in liquid: 
> https://help.blockstream.com/hc/en-us/articles/95127583-How-do-I-issue-an-asset-on-Liquid-
>
> 2.If no, is anyone working or planning to work on it?
>
> 3.I had read few things about Omni BOLT which could solve this problem but 
> not sure about status of project and development: 
> https://github.com/omnilaboratory/OmniBOLT-spec
>
> Few use cases for tokens on lightning:
>
> 1.DEX
> 2.Stablecoins
> 3.Liquidity: If projects could incentivize users with native tokens that are 
> associated with the project on every LN channel opened it would improve 
> liquidity.

I heard before that the RGB colored coin project had plans to be compatible 
with Lightning so that channels could be denominated in an issued asset.

Most plans for colored coins on Lightning generally assume that each channel 
has just a single asset, as that seems to be simpler, at least as a start.
However, this complicates the use of such channels for forwarding, as we would 
like to restrict channel gossip to channels that *any* node can easily prove 
actually exist as a UTXO onchain.
Thus, colored coins would need to somehow be provable as existing to *any* node 
(or at least those that support colored coins somehow) on the LN.

Blockstream I believe has plans to include support for Liquid-issued assets in 
C-Lightning somehow; C-Lightning already supports running on top of Liquid 
instead of directly on the Bitcoin blockchain layer (but still uses Bitcoin for 
the channel asset type).

Generally, the assumption is that there would be a Lightning Network where 
channels have different asset types, and you can forward via any channel, 
suffering some kind of asset conversion fee if you have a hop where the 
incoming asset is different from the outgoing asset.


However, do note that some years ago I pointed out that swaps between two 
*different* assets are a form of very lousy American Call Option: 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html

Due to this, issued assets may not be usable on Lightning after all, even if 
someone makes the work to make non-Bitcoin assets on Lightning channels.

I am unaware of any actual decent solutions to the American Call Option 
problem, but it has been a few years since then and someone might have come up 
with a solution by now (we hope, maybe).
I believe CJP had a trust-requiring solution: 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001292.html 
and https://bitonic.nl/public/slowdown_prevention.pdf
Here is a paper which requires Ethereum (I have not read it because it required 
Ethereum): https://eprint.iacr.org/2019/896.pdf

It may be possible to use Barrier Escrows: 
https://suredbits.com/payment-points-implementing-barrier-escrows/
Barrier Escrows are still trusted (and I think they can serve as the RM role in 
the CJP paper?) to operate correctly, but the exact use of their service is 
blinded to them.
Of course, any single participant of a multi-participant protocol can probably 
unblind the Barrier Escrow, so still not a perfectly trustless solution.



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

Re: [Lightning-dev] Inherited IDs - A safer, more powerful alternative to BIP-118 (ANYPREVOUT) for scaling Bitcoin

[jlspc via Lightning-dev]

Response to email from Anthony Towns sent on 20210918 at 11:37:40 UTC
==
aj,

Thanks for taking the time to go through my paper on inherited IDs (IIDs). 
Also, thanks for your concise and accurate description of the IID proposal and 
the 2Stage channel protocol. I'm glad you feel the 2Stage protocol might be 
better than eltoo for a two-party channel.

I want to address other parts of the paper that were obviously not as clear, as 
they led to two important misunderstandings.

First, there is the issue of the use of an operator in the "timeout trees", 
"update-forest" and "challenge-and-response" factory protocols. While those 
protocols do include a party that is designated as the "operator", the operator 
is in no way a trusted party. While it's true that one would prefer an operator 
that follows the protocol fully and promptly, as that would allow one to keep 
the protocol off-chain, the operator can never take funds or prevent others 
from obtaining the funds that are due to them. In fact, this is exactly 
analogous to the selection of the party with whom one shares a two-party 
lightning channel. If one views lightning as being trust-free, then one will 
also view "timeout trees", "update-forest" and "challenge-and-response" to be 
trust-free.

Second, there is the question of whether or not IIDs can be simulated with 
anyprevout. I don't believe that they can. Consider for example the case where 
Alice has an on-chain funding transaction F1 with output F1:0 that will be 
spent by a (currently off-chain) transaction F2 with output F2:0 that will be 
spent by a settlement transaction S. Assume further that there is an on-chain 
control transaction C1 with output C1:0 owned by untrusted operator O, where 
C1:0 will be spent by a (currently off-chain) transaction C2 with output C2:0 
that may, in certain cases, also be spent by S. In particular, assume F1 puts a 
covenant on F2 such that F2 puts a covenant on S, where the covenant on S can 
be met by either: A) waiting a CSV delay of one time unit (defined to be long 
enough to allow a party with a competing transaction to put that competing 
transaction on-chain first) and then spending only F2:0 (where F2:0 is 
referenced via IID) and giving ownership of S:0 to Alice, or B) waiting until a 
CLV reaches time T_lock and then spending both F2:0 and C2:0 (where F2:0 and 
C2:0 are referenced via IIDs).

Assume that after Alice put F1 on-chain she wants to transfer ownership of the 
output S:0 to Bob without having to put F2 or S on-chain. She can do this with 
IIDs as follows. First, Alice asks the untrusted operator O to put C2 on-chain 
where C2 puts a covenant on S that forces S to spend both F2:0 and C2:0 (where 
F2:0 and C2:0 are referenced via IIDs) and to give ownership of S:0 to Bob (by 
making it spendable using Bob's public key).

There are two cases. First, if O promptly puts the desired C2 on-chain, then 
Alice and Bob can wait until T_lock (while putting nothing else on-chain), at 
which point Bob can be assured that he owns S:0 (as any attempt by Alice to 
spend S:0 by meetiing the covenant using case A above can be thwarted by Bob 
putting S on-chain first using case B above). Second, if O puts a different C2 
on-chain, or fails to put any C2 on-chain promptly, Alice can reclaim her funds 
by putting F2 on-chain, waiting one time window, and then putting S on-chain 
using case A above.

Thus, IIDs provide a trust-free means for Alice to transfer funds from F1 to a 
party that is unknown to Alice when she puts F1 on-chain. I see two problems in 
tryinig to use anyprevout to achieve the same result. First, I don't know of 
any mechanism by which Alice can create a covenant that F2 puts on S which 
implements case B above. In some other settings, I can understand how one could 
use unique single-use keys in place of IID outputs. However, in this setting I 
don't see how to define a covenant that F2 puts on S that in case B forces the 
other input to spend C2:0, as signatures that are evaluated in spending F2:0 
don't commit to the output scripts of other inputs to S. Second, and more 
fundamentally, even if one could define a covenant that F2 puts on S in case B 
forcing the other input to be signed by a single-use key owned by O, that still 
wouldn't unconditionally transfer ownership to Bob (without putting F2 and S 
on-chain). That's because in order to have single-use keys play the role of 
IIDs, they have to truly be single-use and there is no way Bob can know that O 
won't just sign some other S' that competes with S and sends S':0 to O, thus 
stealing the funds. Please let me know if I've missed something here.

The example above isn't very useful, as it doesn't cut down on the number of 
on-chain transactions required to transfer ownership from Alice to Bob. 
However, it does capture the core functionality that IIDs provide that (I 
believe) anyprevout does not provide. This functionality is 

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

[Matt Corallo]

On 10/12/21 12:57, Olaoluwa Osuntokun wrote:

Hi Fabrice,

 > 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.

Appreciate the hard work from Arcane on putting together this report. That
said, our role wasn't to review the entire report, but instead to provide
feedback on questions they had. Had we reviewed the section in question, we
would have spotted those errors and told the authors to fix them. Mistakes
happen, and we're glad it got corrected.

Also note that lnd has _never_ referred to itself as the "reference"
implementation.  A few years ago some other implementations adopted that
title themselves, but have since adopted softer language.

 > 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).

I think it's worth briefly revisiting a bit of history here w.r.t the github
org in question. In the beginning, the lightningnetwork github org was
created by Joseph, and the lightningnetwork/paper repo was added, the
manuscript that kicked off this entire thing. Later lightningnetwork/lnd was
created where we started to work on an initial implementation (before the
BOLTs in their current form existed), and we were added as owners.
Eventually we (devs of current impls) all met up in Milan and decided to
converge on a single specification, thus we added the BOLTs to the same
repo, despite it being used for lnd and knowingly so.

We purposefully made a _new_ lightninglabs github org as we wanted to keep
lnd, the implementation distinct from any of our future commercial
products/services. To this day, we've architected all our paid products to
be built _on top_ of lnd, rather than within it. As a result, users always
opt into these services.

As it seems the primary grievance here is collocating an implementation of
Lightning along with the _specification_ of the protocol, and given that the
spec was added last, how about we move the spec to an independent repo owned
by the community? I currently have github.com/lightning , and would be 
happy

to donate it to the community, or we could create a new org like
"lightning-specs" or something similar. We could then move the spec (the
BOLTs and also potentially the bLIPs since some devs want it to be within
its own repo) there, and have it be the home for any other
community-backed/owned projects.  I think the creation of a new github
organization would also be a good opportunity to further formalize the set
of stakeholders and the general process related to the evolution of
Lightning the protocol.

Thoughts?


No super strong opinion on where things end up, but roughly agree they should be separate. In other 
words, this proposal sounds good to me, want to set it up?


Matt

___
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] Removing lnd's source code from the Lightning specs repository

[lisa neigut]

Love the idea of moving the specs etc to github.com/lightning, thanks so
much for generously offering to donate this Laolu. Strong ACK from me.

Given how difficult the existing org is wrt ownership etc, moving to a new
one makes a lot of sense to me.

Thanks Fabrice for bringing this up so we could discuss it and get a better
understanding of the difficulties with the existing situation.

- nifty

On Wed, Oct 13, 2021 at 00:48 Damian Mee  wrote:

> While I don't partake in the conversations too often, I just want to say I
> strongly support Olaoluwa suggestion.  AFAIAA there's a lot of automations,
> dependencies, dockerfiles, or direct links to files that rely on the
> location of lnd github repo, and I'm sure not all of it would be able to
> handle Github redirect gracefully.  While accessing spec is mostly a
> human/browser activity, where dealing with redirects is much easier.
>
> Plus, github.com/lightning/spec, github.com/lightning/bolts, and/or
> github.com/lightning/rfc would all be trivial to remember, and quick to
> type.
>
> On Tue, Oct 12, 2021 at 2:57 PM Olaoluwa Osuntokun 
> wrote:
>
>> Hi Fabrice,
>>
>> > 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.
>>
>> Appreciate the hard work from Arcane on putting together this report. That
>> said, our role wasn't to review the entire report, but instead to provide
>> feedback on questions they had. Had we reviewed the section in question,
>> we
>> would have spotted those errors and told the authors to fix them. Mistakes
>> happen, and we're glad it got corrected.
>>
>> Also note that lnd has _never_ referred to itself as the "reference"
>> implementation.  A few years ago some other implementations adopted that
>> title themselves, but have since adopted softer language.
>>
>> > 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).
>>
>> I think it's worth briefly revisiting a bit of history here w.r.t the
>> github
>> org in question. In the beginning, the lightningnetwork github org was
>> created by Joseph, and the lightningnetwork/paper repo was added, the
>> manuscript that kicked off this entire thing. Later lightningnetwork/lnd
>> was
>> created where we started to work on an initial implementation (before the
>> BOLTs in their current form existed), and we were added as owners.
>> Eventually we (devs of current impls) all met up in Milan and decided to
>> converge on a single specification, thus we added the BOLTs to the same
>> repo, despite it being used for lnd and knowingly so.
>>
>> We purposefully made a _new_ lightninglabs github org as we wanted to keep
>> lnd, the implementation distinct from any of our future commercial
>> products/services. To this day, we've architected all our paid products to
>> be built _on top_ of lnd, rather than within it. As a result, users always
>> opt into these services.
>>
>> As it seems the primary grievance here is collocating an implementation of
>> Lightning along with the _specification_ of the protocol, and given that
>> the
>> spec was added last, how about we move the spec to an independent repo
>> owned
>> by the community? I currently have github.com/lightning, and would be
>> happy
>> to donate it to the community, or we could create a new org like
>> "lightning-specs" or something similar. We could then move the spec (the
>> BOLTs and also potentially the bLIPs since some devs want it to be within
>> its own repo) there, and have it be the home for any other
>> community-backed/owned projects.  I think the creation of a new github
>> organization would also be a good opportunity to further formalize the set
>> of stakeholders and the general process related to the evolution of
>> Lightning the protocol.
>>
>> Thoughts?
>>
>> -- Laolu
>>
>> On Fri, Oct 8, 2021 at 5:25 PM 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 

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

[Damian Mee]

While I don't partake in the conversations too often, I just want to say I
strongly support Olaoluwa suggestion.  AFAIAA there's a lot of automations,
dependencies, dockerfiles, or direct links to files that rely on the
location of lnd github repo, and I'm sure not all of it would be able to
handle Github redirect gracefully.  While accessing spec is mostly a
human/browser activity, where dealing with redirects is much easier.

Plus, github.com/lightning/spec, github.com/lightning/bolts, and/or
github.com/lightning/rfc would all be trivial to remember, and quick to
type.

On Tue, Oct 12, 2021 at 2:57 PM Olaoluwa Osuntokun 
wrote:

> Hi Fabrice,
>
> > 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.
>
> Appreciate the hard work from Arcane on putting together this report. That
> said, our role wasn't to review the entire report, but instead to provide
> feedback on questions they had. Had we reviewed the section in question, we
> would have spotted those errors and told the authors to fix them. Mistakes
> happen, and we're glad it got corrected.
>
> Also note that lnd has _never_ referred to itself as the "reference"
> implementation.  A few years ago some other implementations adopted that
> title themselves, but have since adopted softer language.
>
> > 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).
>
> I think it's worth briefly revisiting a bit of history here w.r.t the
> github
> org in question. In the beginning, the lightningnetwork github org was
> created by Joseph, and the lightningnetwork/paper repo was added, the
> manuscript that kicked off this entire thing. Later lightningnetwork/lnd
> was
> created where we started to work on an initial implementation (before the
> BOLTs in their current form existed), and we were added as owners.
> Eventually we (devs of current impls) all met up in Milan and decided to
> converge on a single specification, thus we added the BOLTs to the same
> repo, despite it being used for lnd and knowingly so.
>
> We purposefully made a _new_ lightninglabs github org as we wanted to keep
> lnd, the implementation distinct from any of our future commercial
> products/services. To this day, we've architected all our paid products to
> be built _on top_ of lnd, rather than within it. As a result, users always
> opt into these services.
>
> As it seems the primary grievance here is collocating an implementation of
> Lightning along with the _specification_ of the protocol, and given that
> the
> spec was added last, how about we move the spec to an independent repo
> owned
> by the community? I currently have github.com/lightning, and would be
> happy
> to donate it to the community, or we could create a new org like
> "lightning-specs" or something similar. We could then move the spec (the
> BOLTs and also potentially the bLIPs since some devs want it to be within
> its own repo) there, and have it be the home for any other
> community-backed/owned projects.  I think the creation of a new github
> organization would also be a good opportunity to further formalize the set
> of stakeholders and the general process related to the evolution of
> Lightning the protocol.
>
> Thoughts?
>
> -- Laolu
>
> On Fri, Oct 8, 2021 at 5:25 PM 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 

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

[Olaoluwa Osuntokun]

Hi Fabrice,

> 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.

Appreciate the hard work from Arcane on putting together this report. That
said, our role wasn't to review the entire report, but instead to provide
feedback on questions they had. Had we reviewed the section in question, we
would have spotted those errors and told the authors to fix them. Mistakes
happen, and we're glad it got corrected.

Also note that lnd has _never_ referred to itself as the "reference"
implementation.  A few years ago some other implementations adopted that
title themselves, but have since adopted softer language.

> 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).

I think it's worth briefly revisiting a bit of history here w.r.t the github
org in question. In the beginning, the lightningnetwork github org was
created by Joseph, and the lightningnetwork/paper repo was added, the
manuscript that kicked off this entire thing. Later lightningnetwork/lnd was
created where we started to work on an initial implementation (before the
BOLTs in their current form existed), and we were added as owners.
Eventually we (devs of current impls) all met up in Milan and decided to
converge on a single specification, thus we added the BOLTs to the same
repo, despite it being used for lnd and knowingly so.

We purposefully made a _new_ lightninglabs github org as we wanted to keep
lnd, the implementation distinct from any of our future commercial
products/services. To this day, we've architected all our paid products to
be built _on top_ of lnd, rather than within it. As a result, users always
opt into these services.

As it seems the primary grievance here is collocating an implementation of
Lightning along with the _specification_ of the protocol, and given that the
spec was added last, how about we move the spec to an independent repo owned
by the community? I currently have github.com/lightning, and would be happy
to donate it to the community, or we could create a new org like
"lightning-specs" or something similar. We could then move the spec (the
BOLTs and also potentially the bLIPs since some devs want it to be within
its own repo) there, and have it be the home for any other
community-backed/owned projects.  I think the creation of a new github
organization would also be a good opportunity to further formalize the set
of stakeholders and the general process related to the evolution of
Lightning the protocol.

Thoughts?

-- Laolu

On Fri, Oct 8, 2021 at 5:25 PM 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 

[Lightning-dev] Issue assets on lightning

[Prayank via Lightning-dev]

Hello everyone,

I wanted to know few things related to asset issuance on lightning:

1.Is it possible to issue assets on LN right now? If yes, what's the process 
and is it as easy as few commands in liquid: 
https://help.blockstream.com/hc/en-us/articles/95127583-How-do-I-issue-an-asset-on-Liquid-

2.If no, is anyone working or planning to work on it?

3.I had read few things about Omni BOLT which could solve this problem but not 
sure about status of project and development: 
https://github.com/omnilaboratory/OmniBOLT-spec

Few use cases for tokens on lightning:

1.DEX2.Stablecoins3.Liquidity: If projects could incentivize users with native 
tokens that are associated with the project on every LN channel opened it would 
improve liquidity.


-- 
Prayank

A3B1 E430 2298 178F
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Fabrice Drouin]

On Tue, 12 Oct 2021 at 01:14, Martin Habovštiak
 wrote:
>
> I can confirm I moved a repository few months ago and all links kept working 
> fine.
>

Yes, github makes it really easy, and you keep your issues, PRs,
stars, .. depending on your dev/packaging you may need to rename
packages (something java/scala/... devs have to do from time to time)
but it's also very simple.

The issue here is not technical.

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

[Lightning-dev] Block Header commit (c93824e)

[Skyler Saleebyan]

Hi everyone,

Recently there was a commit to change pings from including random data to
now including state data: the most recent bitcoin block header.

https://github.com/lightningnetwork/lnd/pull/5621

I was wondering if there was a discussion around the possible risks for
continuously broadcasting your most recent state to the network. Are there
no counterparty risks associated with this or is the attack surface just
too small/unrealistic outside edge cases?

If I were to just spitball a couple of ideas (and would welcome other
examples), with this data I would wonder if:
a) you could use block header update delays to de-anonymize/identify/locate
nodes by using update times/uncle blocks/fingerprinting attacks
b) any counterparty risks exist from an attacker node pretending to be on
the same block as an out of date node

If the security story around this update has been discussed in detail I'd
love to know where to read more.

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