Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort
Hey Rusty, No matter how we agree for the process I suggest to create a wiki page on which we make it transparent and link to it from README.md. The current process was new to me and I think one cannot expect newcomers to read through the entire Mailinglist. As soon as we have an agreement I can create this PR together with more useful information for newcomers. Best regards Rene Am Di., 27. Nov. 2018, 01:13 hat Matt Corallo geschrieben: > +100 for IRC meetings, though, really, I'd much much stronger prefer > substantive discussion happen on GitHub or the mailing list. Doing > finalization in a live meeting is really unfair to those who can't find the > time to attend regularly (or happen to miss the one where that thing was > discussed that they care about). > > > On Nov 26, 2018, at 18:29, Rusty Russell wrote: > > > > Hi all, > > > >As you may know, for 1.0 spec we had a biweekly Google Hangout, > > at 5:30am Adelaide time (Monday 19:00 UTC, or 20:00 UTC Q3/4). You can > > see the minutes of all meetings here: > > > > > https://docs.google.com/document/d/1oU4wxzGsYd0T084rTXJbedb7Gvdtj4ax638nMkYUmco > > > > The current process rules are: > > > > 1. Any substantive spec change requires unanimous approval at the > > meeting before application. > > 2. Any implementation changes generally require two interoperable > > implementations before they are considered final. > > 3. "typo, formatting and spelling" fixes which can be applied after two > > acks without a meeting necessary. > > > > It's time to revisit this as we approach 1.1: > > > > 1. Should we move to an IRC meeting? Bitcoin development does this. > > It's more inclusive, and better recorded. But it can be > > lower-bandwidth. > > > > 2. Should we have a more formal approval method for PRs, eg. a > > "CONSENSUS:YES" tag we apply once we have acks from two teams and no > > Naks, then a meeting to review consensus, followed by "FINAL" tag and > > commit the next meeting? That gives you at least two weeks to > > comment on the final draft. > > > > Side note: I've added milestones to PRs as 1.0/1.1; I'm hoping to clear > > all 1.0 PRs this week for tagging in the next meeting, then we can start > > on 1.1 commits. > > > > Thanks! > > Rusty. > > ___ > > 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 > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort
+100 for IRC meetings, though, really, I'd much much stronger prefer substantive discussion happen on GitHub or the mailing list. Doing finalization in a live meeting is really unfair to those who can't find the time to attend regularly (or happen to miss the one where that thing was discussed that they care about). > On Nov 26, 2018, at 18:29, Rusty Russell wrote: > > Hi all, > >As you may know, for 1.0 spec we had a biweekly Google Hangout, > at 5:30am Adelaide time (Monday 19:00 UTC, or 20:00 UTC Q3/4). You can > see the minutes of all meetings here: > > > https://docs.google.com/document/d/1oU4wxzGsYd0T084rTXJbedb7Gvdtj4ax638nMkYUmco > > The current process rules are: > > 1. Any substantive spec change requires unanimous approval at the > meeting before application. > 2. Any implementation changes generally require two interoperable > implementations before they are considered final. > 3. "typo, formatting and spelling" fixes which can be applied after two > acks without a meeting necessary. > > It's time to revisit this as we approach 1.1: > > 1. Should we move to an IRC meeting? Bitcoin development does this. > It's more inclusive, and better recorded. But it can be > lower-bandwidth. > > 2. Should we have a more formal approval method for PRs, eg. a > "CONSENSUS:YES" tag we apply once we have acks from two teams and no > Naks, then a meeting to review consensus, followed by "FINAL" tag and > commit the next meeting? That gives you at least two weeks to > comment on the final draft. > > Side note: I've added milestones to PRs as 1.0/1.1; I'm hoping to clear > all 1.0 PRs this week for tagging in the next meeting, then we can start > on 1.1 commits. > > Thanks! > Rusty. > ___ > 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
[Lightning-dev] [META] Organization of 1.1 Spec Effort
Hi all, As you may know, for 1.0 spec we had a biweekly Google Hangout, at 5:30am Adelaide time (Monday 19:00 UTC, or 20:00 UTC Q3/4). You can see the minutes of all meetings here: https://docs.google.com/document/d/1oU4wxzGsYd0T084rTXJbedb7Gvdtj4ax638nMkYUmco The current process rules are: 1. Any substantive spec change requires unanimous approval at the meeting before application. 2. Any implementation changes generally require two interoperable implementations before they are considered final. 3. "typo, formatting and spelling" fixes which can be applied after two acks without a meeting necessary. It's time to revisit this as we approach 1.1: 1. Should we move to an IRC meeting? Bitcoin development does this. It's more inclusive, and better recorded. But it can be lower-bandwidth. 2. Should we have a more formal approval method for PRs, eg. a "CONSENSUS:YES" tag we apply once we have acks from two teams and no Naks, then a meeting to review consensus, followed by "FINAL" tag and commit the next meeting? That gives you at least two weeks to comment on the final draft. Side note: I've added milestones to PRs as 1.0/1.1; I'm hoping to clear all 1.0 PRs this week for tagging in the next meeting, then we can start on 1.1 commits. Thanks! Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] lookupinvoice
Hi Rusty, Thanks for your reply. I'm using the C lightning repo for my project( https://github.com/ElementsProject/lightning). Sorry, I framed the question wrongly. Yes, I can use listinvoices to look up for the invoices created at the node. My scenario is something like this, I'm looking up whether an invoice gets paid or not at the receiver end. For that at this point, I'm calling waitinvoice to see whether an invoice gets paid or not. I would like to know is there any way that the receiver could be aware that the particular invoice created by it paid or not. The problem is using waitinvoice in my case, it's making my process hang till the invoice gets paid. Some workaround which I'm using for this problem is I'm looking up the difference in amount of the label "msatoshi_to_us" while running the listpeers command. Thank You. Regards, Sarat G On Mon, Nov 26, 2018 at 8:59 AM Rusty Russell wrote: > Sarat G writes: > > Hi, > > > > I'm been working on the LN repo for a while now. I would like to know if > > there is any way that a payee can lookup the invoice it gets paid, i.e > > similar to the 'lookupinvoice' command as provided by the lnd(Golang). > > Hi Sarat, > > I'm confused; "the LN repo" is ambigious, as there are several, > each with their own places to ask questions: > > https://github.com/ACINQ/eclair-wallet/ > https://github.com/ElementsProject/lightning > https://github.com/LightningNetwork/lnd/ > https://github.com/nayutaco/ptarmigan > https://github.com/rust-bitcoin/rust-lightning > > Then of course there's the spec repo as well, which guides us all: > > https://github.com/lightningnetwork/lightning-rfc > > But AFAICT (though your question is off-topic for this list): > > lnd has lookupinvoice which looks up by hash[1] > eclair has checkpayment which looks up by hash or bolt11[2] > c-lightning has listinvoices which can lookup by label[3], or >wait(any)invoice[4] which is used for polling. > > Would love someone to write a rosetta stone for the different APIs! > > Cheers, > Rusty. > > [1] https://api.lightning.community/#lookupinvoice > [2] https://github.com/ACINQ/eclair/wiki/API > [3] > https://github.com/ElementsProject/lightning/blob/master/doc/lightning-listinvoices.7.txt > [4] > https://github.com/ElementsProject/lightning/blob/master/doc/lightning-waitanyinvoice.7.txt > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Base AMP
Good morning Johan, I believe what Rusty refers to here is a probe by an intermediate node, rather than a probe by the source node (who, as we know, already knows whether the payee supports AMP or not, by the invoice). Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, November 26, 2018 3:58 PM, Johan Torås Halseth wrote: > This shouldn't be problem, as the invoice will already indicate that the node > supports BaseAMP. If you have a reason to not reveal that you support BAMP > for certain invoices, you'll just not specify it in the invoice, and act > non-BAMPy when receiving payments to this payment hash. > > Of course, this will also be opt-in for both sides and won't affect existing > nodes in any way. > > Cheers, > Johan > > On Wed, Nov 21, 2018 at 11:54 PM Rusty Russell wrote: > >> Johan Torås Halseth writes: >>> Seems like we can restrict the changes to BOLT11 by having the receiver >>> assume NAMP for incoming payments < invoice_amount. (with some timeout of >>> course, but that would need to be the case even when the sender is >>> signalling NAMP). >> >> This would effectively become a probe for Base AMP; if you get a partial >> payment error, it's because the recipient didn't support Base AMP. >> >> Seems cleaner to have a flag, both on BOLT11 and inside the onion. Then >> it's explicitly opt-in for both sides and doesn't affect existing nodes >> in any way. >> >> Cheers, >> Rusty.___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
