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

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

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

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] Proposal for Advertising Channel Liquidity

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

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] Dual Funding Proposal

> > > >++ ++ > > 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] Splicing Proposal: Now with RBF

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] Dual Funding Proposal

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] A proposal for up-front payments.

> 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

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] DRAFT: interactive tx construction protocol

> 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

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

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

> 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

[Lightning-dev] DRAFT: interactive tx construction protocol

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] DRAFT: interactive tx construction protocol

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 >

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

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

> 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

> 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

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

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

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

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.

Re: [Lightning-dev] #zerobasefee

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"

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

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

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

[Lightning-dev] c-lightning discord community

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] Full Disclosure: CVE-2021-41591/ CVE-2021-41592 / CVE-2021-41593 "Dust HTLC Exposure Considered Harmful"

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] Achieving Zero Downtime Splicing in Practice via Chain Signals

Adding a noticeable on-chain signal runs counter to the goal of the move to taproot / gossip v2, which is to make lightning's onchain footprint indistinguishable from any other onchain usage. I'm admittedly a bit confused as to why onchain signals are even being seriously proposed. Aside from

Re: [Lightning-dev] Achieving Zero Downtime Splicing in Practice via Chain Signals

cuts down on the ability to send out these 'urgent' messages with any frequency. ~nifty On Wed, Jun 29, 2022 at 7:43 PM lisa neigut wrote: > Adding a noticeable on-chain signal runs counter to the goal of the move > to taproot / gossip v2, which is to make lightning's onchain footprint > ind

[Lightning-dev] Core-Lightning Release v0.12.0 [Web 8-init]

We're pleased to announce the 0.12.0 release of core-lightning, named by @adi2011. **Developers**: please note the Great Msat Migration in the APIs! ## Highlights for Users - *NEW* Built-in `bookkeeper` plugin! This plugin tracks all movements of msats for your node, gives you a better idea of

[Lightning-dev] Fee Ratecards (your gateway to negativity)

Hi all, I've been talking about them for a bit[^1], now[^2], but here's a more formal proposal for fee ratecards. Spec PR + implementation to come. ## What is a fee ratecard? A ratecard is a set of four values, positive or negative, that price different bands of available liquidity for a

[Lightning-dev] CLN Release: v0.12.1 - Web 8 init (dot one)

Hi all, We'd like to announce the 0.12.1 release[1] of core-lightning, named by @adi2011. This is a point release with a few bug fixes and build improvements: it's a recommended upgrade from 0.12.0, with no new features. For a list of differences, please see [v0.12.0..v0.12.1](

Re: [Lightning-dev] Fee Ratecards (your gateway to negativity)

Some interesting points here. Will try to respond to some of them. > pathfinding algorithms which depend on unscalable data collection Failed payment attempts are indistinguishable from data collection probing. I don't think it's realistic to think that payments are going to stop failing in an