Fabrice Drouin writes:
> Hello,
>
>> 1. Rather than trying to agree on what fees will be in the future, we
> > should use an OP_TRUE-style output to allow CPFP (Roasbeef)
>
> We could also use SIGHASH_ANYONECANPAY|SIGHASH_SINGLE for HTLC txs, without
> adding the "OP_TRUE" output to the comm
Hi all,
Everywhere in the protocol where we negotiate, we've had
problems: what do you do if you can't agree? In most cases, we've
settled on defacto generally-accepted values which aren't mentioned
anywhere in the spec (I've skimmed codebases below, looked at defaults).
I'd like to re-ex
Olaoluwa Osuntokun writes:
> Hi Rusty,
>
> Happy to get the splicing train rolling!
>
>> We've had increasing numbers of c-lightning users get upset they can't
>> open multiple channels, so I guess we're most motivated to allow splicing
> of
>> existing channels
>
> Splicing isn't a substitute for
Rusty Russell writes:
> If we're going to do side splice-in like this, I would use a very
> different protocol: the reason for this protocol was to treat splice-in
> and splice-out the same, and inline splice-in requires wait time. Since
> splice-out doesn't, we don'
ZmnSCPxj writes:
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 2:36 PM, Rusty Russell
> wrote:
>
>> ZmnSCPxj zmnsc...@protonmail.com writes:
>>
>> > Good morning Rusty and list,
>> >
>
ZmnSCPxj writes:
> Good morning Rusty and list,
>
>>
>> 1. Rather than trying to agree on what fees will be in the future, we
>> should use an OP_TRUE-style output to allow CPFP (Roasbeef)
>>
>
> My understanding is that this would require some base-layer changes at
> Bitcoin level first? A
Hi all,
There have been a number of suggested changes to the commitment
transaction format:
1. Rather than trying to agree on what fees will be in the future, we
should use an OP_TRUE-style output to allow CPFP (Roasbeef)
2. The `remotepubkey` should be a BIP-32-style, to avoid the
ZmnSCPxj writes:
> Good morning Rusty,
>
> In BOLT #2 we currently impose a 2^24 satoshi limit on total channel
> capacity. Is splicing intended to allow violation of this limit? I do not
> see it mentioned in the proposal. Can I splice 21 million bitcoins on a
> 1-satoshi channel?
Good quest
Christian Decker writes:
> On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell wrote:
>
>> > * Once we have enough confirmations we merge the channels (either
>> > automatically or with the next channel update). A new commitment tx is
>> > being created which now spen
René Pickhardt writes:
> So let us take the example of Splicing in:
> * The situation before splicing is that we have one output in our funding
> tx that is being spent with each commitment tx. (actually if the channel
> was spliced before we have more inputs but that should not change anything)
>
Hi all!
We've had increasing numbers of c-lightning users get upset they
can't open multiple channels, so I guess we're most motivated to allow
splicing of existing channels. Hence this rough proposal.
For simplicity, I've chosen to only allow a single splice at a time.
It's still comple
Pierre writes:
>> But there's no reason to believe that the invoicer has more knowledge about
>> all but the last hop.
>
> I disagree: there is a good chance that the receiver is a 24/7 running
> merchant/website, with a full up-to-date view of the network, whereas
> the payer is most likely a mo
Matt Corallo writes:
> On a related note, it would be nice to get some clarity on appropriate
> usage of the r= field here.
> The way I had implemented it initially was that if an invoice had an r=
> field any publicly-discovered last-hop routes would be ignored as the r=
> data is most likely mor
Olaoluwa Osuntokun writes:
>> This is orothogonal. There's no point probing your own channel, you're
>> presumably probing someone else's.
>
> In my scenario, you're receiving a new HTLC, from some remote party
> unbeknownst to you.
You have incoming and outgoing channels, and no other informati
alias: SLICKERMASTER-
addresses: 165.227.30.200, 2604:a880:2:d0::2065:5001
You can autogenerate an invoice for testnet with:
http://165.227.30.200:8000/cgi-bin/payreq.sh
If there's insufficient incoming capacity, this *won't* produce an 'r'
hint, but will issue a warning.
Chee
Olaoluwa Osuntokun writes:
>> That might not be so desirable, since it leaks the current channel
>> capacity to the user
>
>>From my PoV, the only way a node can protect the _instantaneous_ available
> bandwidth in their channel is to randomly reject packets, even if they have
> the bandwidth to a
Hi all,
I'm considering a change to c-lightning, where `invoice` would
automatically append an 'r' field for a channel which has sufficient
*incoming* capacity for the amount (using a weighted probability across
our peers).
This isn't quite what 'r' was for, but it would be a use
We're pleased to announce c-lightning 0.6.1, named by co-maintainer ZmnSCPxj.
Highlights for c-lightning users
* Less stuck payments: Liveness ping test before locking up funds with peers.
* Better routing: now considers size of channels.
* Fewer spurious closes: fee estimate improvements, and
Christian Decker writes:
> They are orthogonal, I agree, but we should judge their merits
> independently, and not batch the discussions out of convenience.
> In the case of the htlc_maximum_msat I think it will not be
> controversial, but it should get its own proposal and discussion.
BTW, my th
Dmytro Piatkivskyi writes:
> Dear list, pardon me that I haven't investigated the Lightning
> implementations in depth yet, but one discussion has made me wonder how you
> approach the below described situation.
>
> Rene was talking about virtual channels in his article [1]. His motivation
> w
ec forward. Note that this is a highly technical
event focused solely on protocol design; there will be many other
opportunities for people looking to build applications or contribute to
Lightning-related projects.
The Lightning Summit Disorganization Committee:
Elizabeth Stark, Pierre-Marie Pad
James Chiang writes:
> Hello everyone,
> I understand sighash_noinput allows us to reduce the number of stored
> signatures, as it can spend any uxto with the respective one-use pub key
> script.
> In the case of watchtowers, are we not trading off privacy, as we are
> revealing which states are
DING FENG writes:
> Hi,
>
> I'm a junior developer and a bitcoin user.
> And I have read this thread carefully.
>
> I'm very worried about "SIGHASH_NOINPUT".
>
> Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse
> address more dangerous.
No.
A wallet should *never* create a
Olaoluwa Osuntokun writes:
>> Was referring to losing proof-of-payment; that's vital in a system without
>> intermediaries. We have to decide what the lesser evil is.
>
> As is now, we don't have a proper proof of payment. We have a "proof that
> someone paid". A proper proof of payment would be:
at the lesser evil is.
And yeah, I called it Schnorr-Eltoonicorn not only because it's so
pretty, but because actually capturing it will be a saga.
Cheers,
Rusty.
> On Wed, Jul 4, 2018, 4:21 PM Rusty Russell wrote:
>
>> Christian Decker writes:
>>
>> > ZmnSC
Christian Decker writes:
> ZmnSCPxj via Lightning-dev writes:
>> For myself, I think splice is less priority than AMP. But I prefer an
>> AMP which retains proper ZKCP (i.e. receipt of preimage at payer
>> implies receipt of payment at payee, to facilitate trustless
>> on-to-offchain and off-to-
Gregory Maxwell via bitcoin-dev writes:
> On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
> wrote:
>> Hi all,
>>
>> I'd like to pick up the discussion from a few months ago, and propose a new
>> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
>
> I k
I'm delighted someone is fleshing this out!
Splice-out is easy, splice-in is harder.
Note that there are two ways:
1. Broadcast a spend which joins with one or more random outputs and
then maintain both the old and new channels (ie. both sets of
signatures) until it confirms deeply enough.
"David A. Harding" writes:
> On Tue, Jun 19, 2018 at 02:02:51PM -0400, David A. Harding wrote:
>> Anyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual
>> transaction containing the settlement is expected to have (at least) two
>> inputs, with the second one originating the fees.
ZmnSCPxj writes:
>>> Please describe the below:
>>>
>>> 1. Behavior if payment succeeds after T time.
>>> 2. Behavior if payment fails after T time.
>>>
>>> It seems you only described "Behavior if payment succeeds after T time".
>>
>> Ah, sorry if I didn't make that clear. The reputation is inc
CJP writes:
> Hi,
>
> Maybe this is a stupid question, and it is late so maybe I'm
> overlooking something, but I don't want to lose a potentially good
> idea, so here it goes:
>
> Right now, BOLT#3 imposes a certain algorithm for fee estimation. This
> algorithm is likely to be sub-optimal: fee e
Jim Posen writes:
> Thanks for the thoughtful responses.
>
>> You missed the vital detail: that you must prove channel closure if you
>> can't unpeel the onion further. That *will* hit an unresponsive party
>> with a penalty.
>
> Ah, that is a good point. I still find the proposal overall worryin
Anthony Towns via bitcoin-dev writes:
> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev
> wrote:
>> Given the general enthusiasm, and lack of major criticism, for the
>> `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing
Jim Posen writes:
> There are two directions of solutions I have heard: 1) protocol support for
> decrypting the onion route if the HTLC is kept in-flight for too long 2)
> requiring fees even if the payment fails as a cost to the attacker 3) some
> sort of reputation system for nodes.
>
> Option
Jim Posen writes:
> I find it easier to analyze the game theory of these situations if the
> to_remote output is also time-locked by the to_remote_delay. Making the
> consequence of an on-chain settlement symmetric changes the game from
> chicken [1] to a tragedy of the commons [2]. I'm curious ho
Subject correction: 2018-11-08 and 2018-11-09. November, not October.
Thanks AJ...
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Robert Olsson writes:
> Hello all,
>
> I seem to not find a bolt regarding the QR code of node@ip:port
>
> It seems eclair only supports the format hex@ip:port format, and i haven't
> tried any other mobile wallets.
I anticipate a move away from "manually connect to node" and this wart
will be le
Hi all,
Note the date change; it's now November. Same location, same
discussions, and we'll be finalizing the agenda closer to the date.
I'm scouting exact locations for 15-30 people at the moment;
I'll post here once it's finalized, and ask for RSVPs.
Thanks,
Rusty.
___
栗元憲一 writes:
> I'm Kenichi Kurimoto from Japan.
Greetings Kenichi,
I've been wondering what you've been doing, since we've seen
so many of your intelligent questions on the lightning-rfc github!
We have a Google Hangout every two weeks; you're welcome to join if you
want to discuss the
https://github.com/lightningnetwork/lightning-rfc/pull/392
I'll append to this as suggestions come in. I'm trying to find some
cycles to implement it too.
Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lis
Hi all,
We had a kickoff summit for the Lightning Protocol in October
2016 in Milan. I think we're due for another one, so I'm proposing a
date and location which works for me: September 10th and 11th Adelaide,
Australia.
This would be a meeting for development, update and optimi
Andy Schroder writes:
> On 09/14/2017 11:49 PM, Rusty Russell wrote:
>> So, we really need to be able to include a (smaller) return onion to
>> fix this properly. I've added that to:
>>
>>
>> https://github.com/lightningnetwork/lightning-rfc/w
Jim Posen writes:
> My understanding is that the best strategy for choosing a route to send
> funds over is to determine all possible routes, rank them by estimated fees
> based on channel announcements and number of hops, then try them
> successively until one works.
>
> It seems inefficient to m
Olaoluwa Osuntokun writes:
> Hi Rusty,
>
>> 1. query_short_channel_id
>> IMPLEMENTATION: trivial
>
> *thumbs up*
OK, I'm implementing this now, with data packing so we can have more
than one. (Current 0 and the straight array, will then be able to
assess how impactful adding a simple encoder is)
Fabrice Drouin writes:
> On 20 February 2018 at 02:08, Rusty Russell wrote:
>> Hi all,
>>
>> This consumed much of our lightning dev interop call today! But
>> I think we have a way forward, which is in three parts, gated by a new
>> feature bitpair:
&
Hi all,
Christian and I just gave ZmnSCPxj commit access to c-lightning; we
know nothing other than his preferred pronoun and moniker (I'm calling him
Zeeman for short), but ZmnSCPxj has earned our professional respect with over
100 commits, many non-trivial.
He says: "No objectio
Hi Corné!
Indeed, the privacy focus has generally been the payer, rather
than the recipient of funds.
So there are several things we can do to address this, the main
obvious one the ability to provide a "pre-cooked" onion. This would
allow either a payment to an anonymous destina
Hi all,
This consumed much of our lightning dev interop call today! But
I think we have a way forward, which is in three parts, gated by a new
feature bitpair:
1. A query message for a particular shortid.
2. A query message for shortids in a range of blocks.
3. A gossip_timestamp field i
Conner Fromknecht writes:
> IMHO, the current signed invoice + preimage is a very weak proof of payment.
> It's the hash equivalent to proving you own a public key by publishing the
> secret key. There is an assumption that the only way someone could get that
> preimage is by having made a payment
Christian Decker writes:
> Rusty Russell writes:
>> Finally catching up. I prefer the simplicity of the timestamp
>> mechanism, with a more ambitious mechanism TBA.
>
> Fabrice and I had a short chat a few days ago and decided that we'll
> simulate both app
Hi all!
Finally catching up. I prefer the simplicity of the timestamp
mechanism, with a more ambitious mechanism TBA.
Deployment suggestions:
1. This should be a feature bit pair. As usual, even == 'support this or
disconnect', and odd == 'ok even if you don't understand'.
2. This
Olaoluwa Osuntokun writes:
> Hi Y'all,
>
> A common question I've seen concerning Lightning is: "I have five $2
> channels, is it possible for me to *atomically* send $6 to fulfill a
> payment?". The answer to this question is "yes", provided that the receiver
This is awesome! I'm kicking myself
Olaoluwa Osuntokun writes:
> Protocol Overview
> ==
> This design can be seen as a generalization of the single, non-interactive
> payment scheme, that uses decoding of extra onion blobs (EOBs?) to encode
> extra data for the receiver. In that design, the extra data includes a
> pa
Ignatius Rivaldi writes:
> Hi,
>
> I think that there is a potential problem for sellers to accept
> lightning network. They need someone to open a channel with them that is
> filled with bitcoins so that they can start receiving bitcoins from
> other LN users. But what if a buyer can simultane
Benjamin Mord writes:
> One thing I find useful in RFCs is a brief discussion about the meaning of
> terms like MUST, SHOULD, MAY, etc.. as used in the subsequent protocol
> definition.
Hi Benjamin!
Weird, I always find them kinda useless. RFC2119 pretty much
covers it.
> When a BOLT s
Hi all,
Wanted to post some thinking on this for everyone to mull over,
though I know we're all busy.
Your consideration and feedback gratefully accepted!
Problem #1
==
For simplicity, one side (funder) sets fees, but other side
needs to check they're sufficient, and not insanely
Jonathan Underwood writes:
> Hi all,
>
> I have mentioned this to roasbeef re: lnd implementing it... but I am
> wondering if this idea has propagated through the LN community and whether
> other wallets are going to implement it?
>
> Feature:
>
> If the recipient of a payment waiting for a specif
ZmnSCPxj via Lightning-dev writes:
> Good morning Cezary,
>
> Currently, c-lightning can PAY amountless invoices via the "pay" command, but
> cannot CREATE them via the c-lightning "invoice" command.
Good point, I've filed an issue for this, so we don't lose it:
https://github.com/Elem
Andy Schroder writes:
> Andy Schroder
>
> On 12/27/2017 12:56 AM, ZmnSCPxj wrote:
>> Good morning Andy,
>>
>>>
>>> Channel closing
>>> costs dwarf the gains to be made from cheating, however.
>>>
>>> Since millisatoshis is used, is there a maximum channel
>>> funding size?
Mark Friedenbach writes:
> I had always assumed the protocol limits were training wheels, and would be
> shocked and dismayed if that were not the case (and would immediately begin
> work on an alternative fork because such limits would make lightning useless
> for my intended applications).
M
Andy Schroder writes:
> What's the rational for using millisatoshis as the units for lightning
> channels? Aren't you going to loose up to 1/2 of a satoshi when the
> channel is closed?
You can lose up to 0.999 satoshi per in-progress payment, yes. BOLT #3:
The amounts for each output MUS
Stan Kladko writes:
>> If you have a reason to open a channel to an arbitrary node, then other
>> nodes have a reason to open a channel to an arbitrary node, which might be
>> you. Even if the network grows large, that > also means there are more
>> participants who might decide, via whatever
Jonathan Underwood writes:
> iirc they are using the description as a way to join the user data and the
> payment hash on their end.
But the description isn't used when I send a payment. All they get is
the payment_hash.
> htlc me is one node but separates its balance into user accounts that ex
Jonathan Underwood writes:
> Additional comment: we should make a requirement to hide text in the
> description under certain conditions.
>
> ie. "A reader MUST hide information surrounded by curly brackets {}
> including
> the brackets themselves from the UI, and only make the information avaiabl
Edward Marynarz writes:
> On Mon, Dec 11, 2017 at 12:15 AM, Rusty Russell
> wrote:
>
>>
>> In particular, fees are charged on entry to the channel, so if there's
>> an A->B channel, A charges the fee. If you traverse B->C, B charges the
>> fee,
Jonathan Underwood writes:
> Hello all,
>
> Recently I have implemented BOLT11 in node JS. You can find it on github at
> bitcoinjs/bolt11 (check the wip branch, I am still working on tests and
> looking at maybe splitting encode up into two functions, encode and sign,
> if anyone wants to help)
https://docs.google.com/document/d/1WaZDvCX7FsfZbrEMepLdchmDQyyRhY9MTBMF4NeZlOc/edit#
Unusually, we had two minor breaking changes, despite the freeze:
1. `r` fee field is now base+millionths like channel_update.
* Fixes case where there's no amount ('donation address').
* Nobody h
Johan Torås Halseth writes:
> Hi, Edward! Welcome to the mailing list :)
> The fees can indeed be set for each direction of the channel, check out
> https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message
>
> [https://github.com/lightningnet
Shannon Appelcline writes:
> Section 7 says "nodes MAY prune channels should the timestamp of the
> latest `channel_update` be older than 2 weeks (1209600 seconds)"
>
> Yet timestamps are only required to be sequential, not an actual
> timestamp ("The creating node MUST set `timestamp` to be gre
Nicolas Dorier writes:
> I noticed the Commitment Transaction Output script is weak to malleability,
> this can be used to delay confirmation of the revocation.
> Luckily, fixing the situation does not require lots of development.
Oh, wow! FWIW I'm a bit mindblown by your level of adversarial
th
Olaoluwa Osuntokun writes:
> (re-sending as doesn't look like my original mail went through to the list?)
I increased the limit to 80k now.
Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundat
Alan Carbery via Lightning-dev
writes:
> Hi,
>
> All the tutorials that I've read about Lightning describe bi-directional
> channels. However, reading through the draft RFC I'm wondering if it's
> uni-directional only. Can anyone clarify if this is the case and if so then
> is there a reason for
Tomas writes:
> Thank you for your feedback,
>
> On Sun, Nov 12, 2017, at 04:04, Rusty Russell wrote:
>> Malleation is a problem for every commitment transaction: we use HTLC
>> transactions which depend on it. Now, in theory SIGHASH_NOINPUT could
>> be used to work
Hi!
Sorry I've been slack posting previous minutes, but the good
news is we've put them all in one place:
https://docs.google.com/document/d/1oU4wxzGsYd0T084rTXJbedb7Gvdtj4ax638nMkYUmco/edit#heading=h.8iu8f3dcmgj2
Highlights from 2017-11-13:
- Integration tests looking g
Tomas writes:
> HI,
>
> I have some questions regarding the proposal to use SIGHASH_NOINPUT on
> the bitcoin-dev mailing list. [1]
>
> 1. If I understand correctly, the problem of malleated transactions for
> LN is limited to the punishment transaction which is the only one that
> spends an uncon
Louis Willcock writes:
> Rusty, your comments on BIP70 have me interested. Do you have a belief as
> to why it is not used? And I assume you are largely referring to the BIP
> 70-72 collection? Is it a case of App devs just not incorporating the
> functionality in?
I think the lack of adoption is
Cezary Dziemian writes:
> Thank you very much for answers. It is honor that you answered and it is
> also very important for us in Poland. My friend is building Bitcoin ATMs
> and off-course plan to use LN. BTW: In Poland a lot of people believe that
> LN is the next big thing. We have huge pro-LN
Hi Cezary,
This is indeed the right place for such questions at the moment.
Cezary Dziemian writes:
> 1. After LN starts, some group of users will use it, other not. If for
> example, I would like to receive payment for coffee from some user, I don't
> know if user uses LN or not. So, wh
Highlights:
- Onion error format will change
- Much deferred to 1.1
https://docs.google.com/document/d/1i3rX8ZPWlqHVHuZ3DAsbAJSqxyboQidLSroYk9auFEo/edit#
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://list
Andy Schroder writes:
> On 09/03/2017 08:34 PM, Rusty Russell wrote:
>> Andy Schroder writes:
>>> Hello,
>>>
>>> Yes, it seems as though high frequency payments are not a reality. For
>>> high value products that are delivered quickly, "micro
Highlights:
- No significant protocol changes.
- Rusty gets a lesson in bitcoin block endianness he somehow
missed previously.
https://docs.google.com/document/d/1y_JcK66iXqfxLe1ZnlqvFv94MCNVnC6Q2LKVe6-Vu6U/edit?usp=sharing
__
Andy Schroder writes:
> Hello,
>
> Yes, it seems as though high frequency payments are not a reality. For
> high value products that are delivered quickly, "micro" payments are not
> even possible. With my fuel delivery system, the smallest volume of
> product that could be individually payed f
Andy Schroder writes:
> Hello,
>
> I'm looking through BOLT 11. I don't really see an option for a refund
> address like is present in BIP 70. Is this intentional? If so, why do
> you not see that people would possibly want to receive a refund?
Hi!
I never even thought of that requirem
Highlights:
- BOLT 10 (DNS seed) got merged, you can try it now at Christian
Decker's node (dig lseed.bitcoinstats.com gives you some random
testnet nodes).
- Recommendations for 'bitcoin:' URI key and 'lightning:' URI included
in BOLT 11.
- No core protocol changes this week :)
https://
Christian Decker writes:
> Hi Martin,
>
> this is the perfect venue to discuss this, welcome to the mailing list :-)
> Like you I think that using the first forked block as the forkchain's
> genesis block is the way to go, keeping the non-forked blockchain on the
> original genesis hash, to avoid
Nothing groundbreaking, but some PRs finally got merged :)
https://docs.google.com/document/d/1ng6FaOLGS7ZQEsv3kn6W-t2GzQShhD7eFPz-1yFQZm0/edit?usp=sharing
Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
ht
Olaoluwa Osuntokun writes:
>> I think it does already:
>
> Yep! An oversight on my part.
>
>> So, you're suggesting SIGHASH_SINGLE|SIGHASH_ANYONECANPAY?
>
> Precisely. The code modifications required to switch to this signing mode
> are
> trivial.
As per meeting discussion, we're in *NO CHANGES E
Rusty Russell writes:
> https://docs.google.com/document/d/1ng6FaOLGS7ZQEsv3kn6W-t2GzQShhD7eFPz-1yFQZm0/edit?usp=sharing
Some feedback, since I missed what seems like a very productive
discussion!
> HTLC floor created by second-level HTLC transactions
> Pierre points out that shou
https://docs.google.com/document/d/1ng6FaOLGS7ZQEsv3kn6W-t2GzQShhD7eFPz-1yFQZm0/edit?usp=sharing
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Hi all!
Every two weeks we've been running an informal Google Hangout
for implementers of the Lightning spec; as the spec is starting to
freeze, we've decided to formalize it a bit which means opening access
to a wider audience.
The call is at 20:00 UTC every two weeks on Monday:
201 - 290 of 290 matches
Mail list logo
