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 or
nels, but we can 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
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 output
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 in
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)
To
l active HTLCs in a merkle 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 tric
t;
> > That sounds possible, but how would you deal with the exponential
> > blowup 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
I haven’t looked too closely at your proposal, but the first thing that hit me
(2 weeks ago, sorry for not answering right away), is that instead of the basic
flood-the-network-about-channels algorithm that currently is being used, this
makes each route discovery request behave more or less like
I think this might have been discussed somewhere, sometime before: couldn’t we
add an lightning parameter to the bitcoin: url, making the QR codes backwards
compatible?
- Johan
On Fri, Nov 3, 2017 at 2:20, Rusty Russell wrote:
Hi Cezary,
This is indeed the right place for such questions at the
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/lightningnetwork/lightning-rfc/blob/master/07-routi
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
Hi,
Before you can safely broadcast the funding transaction, the two parties
involved in a channel must have signed a commitment transaction spending the
output from the funding transaction. Without segwit, the funding transaction
can be malleated, leaving the commitment transaction invalid, and
sues? ᐧ
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 the
output from the funding t
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: https://github.com/lightningnetwork/lnd/issues/564
[https://github.c
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 chan
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 ve
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’ commit
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 (1)
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
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 claim the HTLC: the presa
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 likel
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 w
the case for a single channel, but if
> you always chose the same channel it reduces how much info is leaked.
>
> Cheers,
> Christian
>
> Johan Torås Halseth writes:
> > Any reason not to include _all_ (up to a limit) incoming channels with
> > sufficient capacity?
>
I agree the r-fields are useful to populate for public channels in many
situations, but care must be taken to not _always_ try them first without
accounting for potentially high fees on those channels.
- Johan
On Wed, Oct 10, 2018 at 5:46 AM Rusty Russell wrote:
> Pierre writes:
> >> But there'
>
> 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.
Compl
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 wat
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 how
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 Ba
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 Lightni
urse, 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
> > ass
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
Hi Pierre and list folks,
I haven't looked at the technical implications of implementing this in
detail, but I like the high-level direction this proposal is taking :)
I think it nicely ties together several concepts that have been proposed
earlier, and with the correct design could give the send
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
https://github.com/bitcoin/bitcoin
inputs/outputs 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 ment
gt;
>
> On Fri, Oct 25, 2019 at 10: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 ou
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
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:
https://api.lightnin
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
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
ocks it will take me to confirm ?") 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 lawfu
40 matches
Mail list logo
