Re: [Lightning-dev] Directionality of the transaction fees

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

Re: [Lightning-dev] Comments on BOLT#11

Just a few quick comments, as any improvements to BOLT#11 are very much appreciated :) * I think we should set a reasonable max length for invoices, that MUST be met. This would simplify internal database logic (since you don’t have to plan for invoices infinitely big), and could make sure the

Re: [Lightning-dev] Invoice without amount

Hi, Cezary, I initially read the issue you created as a bug filing, my bad. I’ve updated it to reflect that it is a feature request. Cheers! Johan On Thu, Jan 11, 2018 at 18:16, Cezary Dziemian wrote: I made issue 5 days ago:

Re: [Lightning-dev] Fee disentanglement for 1.1 spec?

Hi Rusty, This is something I’ve been thinking a bit about, as I’ve stumbled into some of the edge cases you mention. Just to get on the same page: does the other side (non-funder) pay any fees in the current implementation? [1] suggests that the funder pays everything atm (on both sides’

Re: [Lightning-dev] [Question] Unilateral closing during fee increase.

Hi Jonathan, This is definitely a problem! I have a mainnet channel I force closed 2 weeks ago that is still not mined :( With current spec I guess it is not much that can be done other than crossing fingers. For future specs maybe someone could come up with some SIGHASH flag magic to either

[Lightning-dev] Insufficient funder balance for paying fees

Hi all, I am wondering how Eclair and c-lightning is handling the following case, as I wasn’t able to derive exactly how to handle it from the BOLTs. If it is described somewhere, please point me to it, if not, let’s agree on a strategy, and get it in :) Let's say Alice is the funder of the

Re: [Lightning-dev] Insufficient funder balance for paying fees

Hi Pierre, You’re right, that looks very much like the same kind of situation! I agree, it looks from [2] that a node may fail the channel in this case, and that it probably should to not risk end up with all funds in an unpublishable tx. Seems like something that could be used as a DOS attack

Re: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

locked in, because in that case they are releasing the transaction receipt before fully being paid. On Thu, Feb 8, 2018 at 8:41 AM, Johan Torås Halseth < joha...@gmail.com [joha...@gmail.com] > wrote: An obvious way to make this compatible with proof-of-payment would be to require two hashes to cl

Re: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

An obvious way to make this compatible with proof-of-payment would be to require two hashes to claim the HTLC: the presage from the invoice payment hash (as today) + the new hash introduced here. This would give the sender a receipt after only one of the HTLCs was claimed. Would require changes

Re: [Lightning-dev] SegWit and LN

to mature or are there any other issues? ᐧ On Tue, Jan 2, 2018 at 8:01 PM, Johan Torås Halseth < joha...@gmail.com [joha...@gmail.com] > wrote: Hi, Before you can safely broadcast the funding transaction, the two parties involved in a channel must have signed a commitment transaction spending

Re: [Lightning-dev] Rebalancing argument

A simple way to see how rebalancing could be beneficial, is to observe that you only know the channel capacity (not the balance!) of the channels you don’t belong to. If everybody is being good stewards and are rebalancing their channels, then picking a route to send a payment over is more

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

> > This is one of the cases where a simpler solution (relatively > speaking ^^) is to be preferred imho, allowing for future > iterations. > I think we should strive to splice in 1 on-chain tx, as if not the biggest benefit really is lost compared to just closing and reopening the channel.

Re: [Lightning-dev] Recovering protocol for Lightning network

Hi, Margherita, If you haven't already, look into "data loss protection" as defined in the BOLTs. It is similar to to what you are suggesting, with A being able to tell B that it lost state for the A<->B channel, and if B is cooperative it will help A recover its funds. You can also look into

Re: [Lightning-dev] Base AMP

Good evening Z and list, I'm wondering, since these payments are no longer atomic, should we name it accordingly? Cheers, Johan On Tue, Nov 13, 2018 at 1:28 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > I propose the below to support

Re: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes

Neat! I think this is similar to what has been briefly discussed earlier about hybrid packet-switched/circuit-switched payment routing. B doesn't have to care about how the payment gets from C to D, but she knows it must go through D, keeping privacy intact. This would be exactly equivalent to

Re: [Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity

Any reason not to include _all_ (up to a limit) incoming channels with sufficient capacity? Cheers, Johan On Thu, Sep 20, 2018 at 4:12 AM Rusty Russell wrote: > Hi all, > > I'm considering a change to c-lightning, where `invoice` would > automatically append an 'r' field for a channel

Re: [Lightning-dev] Base AMP

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). Cheers, Johan On Wed, Nov 21, 2018 at 3:55 AM ZmnSCPxj via

Re: [Lightning-dev] Base AMP

, 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 in

Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

On Mon, Oct 28, 2019 at 6:16 PM David A. Harding wrote: > A parent transaction near the limit of 100,000 vbytes could have almost > 10,000 outputs paying OP_TRUE (10 vbytes per output). If the children > were limited to 10,000 vbytes each (the current max carve-out size), > that allows relaying

Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

:31 AM Matt Corallo > wrote: > >> I don’te see how? Let’s imagine Party A has two spendable outputs, now >> they stuff the package size on one of their spendable outlets until it is >> right at the limit, add one more on their other output (to meet the >> Carve-

Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

Reviving this old thread now that the recently released RC for bitcoind 0.19 includes the above mentioned carve-out rule. In an attempt to pave the way for more robust CPFP of on-chain contracts (Lightning commitment transactions), the carve-out rule was added in

Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

tputs you can add, but somehow I doubt > its ever going to be a large enough number to matter. > > Matt > > On 10/24/19 1:49 PM, Johan Torås Halseth wrote: > > Reviving this old thread now that the recently released RC for bitcoind > > 0.19 includes the above mentioned carv

Re: [Lightning-dev] Sphinx and Push Notifications

2) lnd is getting the API you need in the next release (v0.10), that let you subscribe to HTLC events. See PR https://github.com/lightningnetwork/lnd/pull/3848. The notification won't be signed (but the stream uses TLS), but that can easily be added using the `signmessage` API:

Re: [Lightning-dev] SIGHASH_SINGLE + update_fee Considered Harmful

Hi, Very good observation, most definitely not a type of attack I forseen! Luckily, it was the plan to phase out update_fee all along, in favor of only accepting the minimum relay fee (zero fee if/when package relay is a reality). If I understand the scenario correctly, that should mitigate this

Re: [Lightning-dev] Why should funders always pay on-chain fees?

Many good thoughts here. Personally I think we should design any changes for a package-relay future, where the commitment can be 0-fee, update_fee doesn't longer exist and fees are only decided upon on channel close. - johan On Wed, Oct 14, 2020 at 10:25 AM Bastien TEINTURIER via Lightning-dev

Re: [Lightning-dev] SIGHASH_SINGLE + update_fee Considered Harmful

onfirm ?") or an economic > decision ("is this HTLC worthy to claim/expire ?"). > > One could argue it's increasing the blockspace footprint as you will use one > more pair of input-output but if you're paying the feerate that's lawful > usage. > > Antoine > &g

[Lightning-dev] Fwd: HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants)

Cross-posting this to the lightning-dev list, as was my intended destination. -- Forwarded message - From: Johan Torås Halseth Date: Thu, Oct 26, 2023 at 12:52 PM Subject: HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants

Re: [Lightning-dev] Dynamic Commitments Part 2: Taprooty Edition

Hi, Laolu. I think it could be worth considering dividing the taprootyness of a channel into two: 1) taproot funding output 2) taproot commitment outputs That way we could upgrade existing channels only on the commitment level, not needing to close or re-anchor the channels using an adapter in

Re: [Lightning-dev] Dynamic Commitments Part 2: Taprooty Edition

n also consider that separately when we get to that > point, IMO. > > Am I missing some important utility of taproot commitment transaction > outputs? > > Matt > > On Oct 27, 2022, at 02:17, Johan Torås Halseth wrote: > >  > Hi, Laolu. > > I think it could

Re: [Lightning-dev] [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

Hi, I wanted to chime in on the "teleport" feature explained by Ruben, as I think exploring something similar for Taro could be super useful in an LN setting. In today's Taro, to transfer tokens you have to spend a UTXO, and present a proof showing that there are tokens committed to in the

Re: [Lightning-dev] [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

Hi Laolu, Yeah, that is definitely the main downside, as Ruben also mentioned: tokens are "burned" if they get sent to an already spent UTXO, and there is no way to block those transfers. And I do agree with your concern about losing the blockchain as the main synchronization point, that seems

Re: [Lightning-dev] [bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants)

e tree, and have the > > spender provide merkle proofs for the HTLCs to claim, claiming the sum > > into a new output. The remainder goes back into a new output with the > > claimed HTLCs removed from the merkle tree. > > > An interesting trick one can do when crea

Re: [Lightning-dev] [bitcoin-dev] HTLC output aggregation as a mitigation for tx recycling, jamming, and on-chain efficiency (covenants)

lowup in the number of combinations? > > In a taproot-world, "swallow the bullet" in terms of witness size growth in > case of non-cooperative closure. > I think this is where introducing an accumulator at the Script level to > efficiently test partial set membership would