[Lightning-dev] c-lightning discord community

2021-10-19 Thread lisa neigut
FYI c-lightning now has a discord server for general questions, dev-chats, and community support. You can join it here: https://discord.gg/WW56GGHavu We're also still on Telegram at https://t.me/lightningd and IRC at #c-lightning on the libera.chat node. ~nifty

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

2021-10-12 Thread 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

Re: [Lightning-dev] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

2021-10-04 Thread lisa neigut
FYI the next version of c-lightning will contain the proposed `max_dust_htlc_exposure_msat` as outlined in #919 ; the given expected vulnerabilities patch table should have reflected this. > The vulnerabilities are expected to be

Re: [Lightning-dev] #zerobasefee

2021-08-15 Thread lisa neigut
The field of economics has done much work over the past few decades demonstrating that “Free” is problematic in practice because humans will go out of their way to externalize costs elsewhere (e.g. time, in the case of lightning), given the promise of freedom. In other words, actors often act

[Lightning-dev] v0.10.1: "eltoo: Ethereum Layer Too"

2021-08-09 Thread lisa neigut
We're pleased to announce the 0.10.1 release of c-lightning , named by @nalinbhardwaj. This is a *recommended* upgrade: payment secrets in invoices are now compulsory, and offers and dual funding drafts have been updated, so these

[Lightning-dev] Interactive tx construction and UTXO privacy, some thoughts

2021-06-28 Thread lisa neigut
Hey all, The dual-funding proposal has been up for a while now, and while we've had some really great reviews from a few people (@ariard + @rustyrussell thanks for your comments in particular). As a refresher, the PR is available here: https://github.com/lightningnetwork/lightning-rfc/pull/851.

[Lightning-dev] [c-lightning] v0.9.2 "Now with 0-of-N Multisig" Released

2020-11-23 Thread lisa neigut
We're pleased to announce the 0.9.2 release of c-lightning, named by Sergi Delgado. This is a significant release with new CLI-level notifications, better channel state reporting, and stable plugin-hook call ordering. Note that

[Lightning-dev] [c-lightning] v0.8.2 Scaling the Ethereum Blockchain

2020-04-30 Thread lisa neigut
We're pleased to announce the 0.8.2 release of c-lightning, named by @arowser . This is a minor release and includes a few new and experimental features, as well as bug-fixes and performance wins. Highlights for Users - New config option --large-channels (also

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-13 Thread lisa neigut
> With PoDLE this would not be possible I think, as you would not be able to open the PoDLE commitment with the other node as the target (if we go with the modified PoDLE which also commits to which node an opening is for, to prevent the pouncing venus flytrap attack). Good question. It should be

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-12 Thread lisa neigut
> Probably so that address reuse is not dinged, i.e. I have two UTXOs with the same address and want to make two different channels with different peers. Having 2 utxos locked to the same pubkey will map to a single H2 value though, which is what is used to flag utxo reuse. With a PoDLE you're

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-11 Thread lisa neigut
> s = k + H(kG || kJ || P || P2 || utxo || receiving-node) x > and as before transfer opening: (P, P2, u, s, e) with receiving-node implicitly reconstructed to do the verification of the Schnorr sig. It's basically a message in a signature. Oh that's *much* nicer than calculating a second

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-10 Thread lisa neigut
to a hash until a valid positive-public key point is found, but without the index. On Mon, Feb 10, 2020 at 5:11 PM lisa neigut wrote: > Here's some thoughts I had on PoDLE's and lightning. An enormous > tip-of-the-hat is due to ZmnSCPxj for surfacing the work that JoinMarket > ha

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-10 Thread lisa neigut
Here's some thoughts I had on PoDLE's and lightning. An enormous tip-of-the-hat is due to ZmnSCPxj for surfacing the work that JoinMarket has done here already. - The initiating message (in the case of open channel, this would be `open_channel2`) is extended to include an 'H2' field in its TLV, a

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-10 Thread lisa neigut
> But if you impose the blockheight - 6 in the Lightning protocol level, and Lightning succeeds (meaning a substantial fraction of blockchain transactions are Lightning opens)... > --- then transactions with `nLockTime` equal to the block they are included in minus 5 will be more common than

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-06 Thread lisa neigut
> I am unsure what is the purpose of this minus 6. The original motivation was to keep the funding transaction from being rejected from the mempool in the case of a re-org, but as you pointed out, the 'next block' is always at -par or ahead of the current chain tip, so I'm not sure this

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-04 Thread lisa neigut
Rusty had some suggestions about how to improve the protocol messages for this, namely adding a serial_id to the inputs and outputs, which can then be reused for deletions. The serial id can then also be used as the ordering heuristic for transaction inputs during construction (replacing current

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-01-29 Thread lisa neigut
hi max — great question. PSBT is a great protocol for wallet interop but a bit overweight for tx collaboration between two peers On Wed, Jan 29, 2020 at 17:29 Max Dignan wrote: > Hey Antoine, > > Would PSBT (BIP 174 - > https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) be a good >

[Lightning-dev] DRAFT: interactive tx construction protocol

2020-01-27 Thread lisa neigut
Some of the feedback I received from the check-in for the dual-funding proposal this past Monday was along the lines that we look at simplifying for breaking it into smaller, more manageable chunks. The biggest piece of the dual-funding protocol update is definitely the move from a single peer

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-07 Thread lisa neigut
> Imagine the following setup: a network of nodes that trust each other The goal of this pre-payment proposal is to remove the need for trusted parties. On Thu, Nov 7, 2019 at 07:38 Joost Jager wrote: > > Isn't spam something that can also be addressed by using rate limits for >> > failures?

[Lightning-dev] c-lightning v0.7.3 "Bitcoin's Proof of Stake" Released

2019-10-28 Thread lisa neigut
We're pleased to announce 0.7.3, named by @trueptolemy Note: new dependency gettext is now required when building from source. *Highlights for Users*- lightningd now supports different SQL backends. This release includes a PostgresSQL driver, in addition to the default sqlite3 driver. - Ability

Re: [Lightning-dev] Dual Funding Proposal

2018-12-03 Thread lisa neigut
> > > >++ ++ > > where node A is the ‘initiator’ and node B is the ‘dual-funder’ > > We currently use the terms funder and fundee, which are now > inaccurate ofc. Perhaps 'opener' and 'accepter' are not great english, > but they map to the messages well?

Re: [Lightning-dev] Dual Funding Proposal

2018-11-28 Thread lisa neigut
On Tue, Nov 27, 2018 at 11:26 PM ZmnSCPxj wrote: > Good morning Lisa, > > Minor comments only, have not studied in detail: > > > > `accept_channel2`: > > [32:temporary_channel_id] > > … // unchanged > > [33:first_per_commitment_point] > > [?: options_tlv] > > options_tlv: > >1. > >

Re: [Lightning-dev] Splicing Proposal: Now with RBF

2018-11-21 Thread lisa neigut
Hello Rusty. Exciting stuff! A few observations: On Fri, Nov 16, 2018 at 12:18 AM Rusty Russell wrote: > ### Confirming a splice: `splice_confirm` > > 1. type: 43 (`splice_confirm`) (`option_splice`) > 2. data: >* [`32`:`channel_id`] >* [`64`:`signature`] >* [`2`:`num_witnesses`] >

Re: [Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-12 Thread lisa neigut
en > insta close (they just drain the network and then no one uses this), I > think > this is a dope idea in general! In the past, I've mulled over similar > constructions under a general umbrella of "Channel Liquidity Markets" > (CLM), > though via extra-protocol negotiation.

Re: [Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-12 Thread lisa neigut
On Wed, Nov 7, 2018 at 10:17 PM Anthony Towns wrote: > On Wed, Nov 07, 2018 at 06:40:13PM -0800, Jim Posen wrote: > > can simply close the channel. So if I'm charging for liquidity, I'd > actually > > want to charge for the amount (in mSAT/BTC) times time. > > So perhaps you could make a market

Re: [Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-12 Thread lisa neigut
Hello ZmnSCPxj, You bring up some good points. On Wed, Nov 7, 2018, 21:19 ZmnSCPxj Good morning Lisa, > > On Wednesday, November 7, 2018 2:17 PM, ZmnSCPxj via Lightning-dev < > lightning-dev@lists.linuxfoundation.org> wrote: > > Good morning Lisa, > > >Should a node be able to request more

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread lisa neigut
To add some context to this, if you start accepting HTLC's for the new balance after the parallel commitment is made, but before the re-anchor is buried, there's the potential for a race condition between a unilateral close (or any revoked commitment transaction) and the re-anchoring commitment