veryone
> benefits more from cooperating than from trying to cheat each other.
> This is very similar to how the current network works.
>
>
> On Wed, Dec 13, 2023 at 12:59 PM Bastien TEINTURIER
> wrote:
> >
> > Hey Keagan,
> >
> > Thanks for your feedback!
>
astien
Le mer. 13 déc. 2023 à 16:28, Peter Todd a écrit :
> On Wed, Dec 13, 2023 at 02:27:13PM +0100, Bastien TEINTURIER wrote:
> > Hi Peter,
> >
> > No, we currently cannot get rid of the remote anchor in favor of the
> > main remote output. That was considered during
Hi Peter,
No, we currently cannot get rid of the remote anchor in favor of the
main remote output. That was considered during the design of anchor
outputs, but that would create the following vulnerability.
Alice opens a channel to Bob: Bob doesn't have a main output in the
commit tx yet. Alice
g fees, the seller could sidestep
> griefing opportunities while not being in the position to use a small
> amount of liquidity to scam a large number of users in rapid succession.
>
> So my question to the list is what can be gained by adding a timelock,
> here?
>
> Keags
>
at
> was the agreed lease amount. Bob can still play games with circular
> routing or force closing with HTLCs outstanding to unlock some of his
> liquidity early, but that is also the case with every other proposal
> so far. Hence the importance of limiting HTLC value in flight.
o keep that liquidity
available for a long time or move it elsewhere.
Cheers,
Bastien
Le ven. 8 déc. 2023 à 09:00, Bastien TEINTURIER a écrit :
> Hey Matt,
>
> > The question then is really: do operators want to buy/sell X sats of
> > inbound flow or Y days of an open channel
,
Bastien
Le jeu. 7 déc. 2023 à 22:18, Matt Morehouse a
écrit :
> On Mon, Dec 4, 2023 at 9:48 AM Bastien TEINTURIER
> wrote:
> >
> > But I've thought about it more, and the following strategy may work:
> >
> > - store three counters for the seller's fu
ice wants
> to add would be in a separate, unencumbered channel.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with Proton Mail secure email.
>
> On Friday, December 1st, 2023 at 5:45 PM, Bastien TEINTURIER <
> bast...@acinq.fr> wrote:
>
>
> > Good morning list,
>
Good morning list,
I've been thinking a lot about liquidity ads recently, and I want to
highlight some subtleties that should be taken into account in the
protocol design. This is a rather long post, but I believe this is
important to make sure we get it right and strike the right balance
between
Hey Matt,
That sounds good to me! Let's settle that during the next spec meeting.
Thank you for the option of hosting a mailing list instance, I'd be happy
to moderate it to share some of the burden.
Bastien
Le dim. 26 nov. 2023 à 17:51, Matt Corallo a
écrit :
> During the last meeting it
ther upgrade that simplifies or needs
> the same thing? (syncrhonous commitment flow; PTLCs; eltoo?)
>
> ~nifty
>
>
> On Tue, Nov 21, 2023 at 4:33 AM Bastien TEINTURIER
> wrote:
>
>> Hey Lisa,
>>
>> Thanks for the update! I believe that moving to CLTV instead
Hi Andy,
> Also, we might want to make it explicit in the spec that you can't
> have duplicate records? Many DNS records allow multiple for
> redundancy. Is that desired here?
Agreed, this should be made explicit in the bLIP. I don't see a reason
to allow duplicate records, so we should require
Hey Lisa,
Thanks for the update! I believe that moving to CLTV instead of CSV is
definitely the right move here.
Regarding the newly added 2nd-stage lease locked transactions, I don't
think that works. The issue is that you don't have an opportunity to
receive signatures for those transactions
; >
> >
> > - Seems to be a bad idea to me. You are relying on certificate
> authorities to prove the ownership of
> > a domain? The certificate authorities are not an authority on domain
> ownership. Also, it seems to me
> > like certificate authorities are a major we
tead of a typical web server.
> At scale, that would be much more difficult for LNURL service providers to
> implement for their potentially thousands to millions of users.
>
> Something like Oblivious HTTP could be promising to remove the knowledge
> of IP for some of the larger LNURL ser
Good morning list,
Most of you already know and love lightning addresses [1].
I wanted to revisit that protocol, to see how we could improve it and
fix its privacy drawbacks, while preserving the nice UX improvements
that it brings.
I have prepared a gist with three different designs that
egwit support also took years.
>
> [1] http://whentaproot.com/
>
>
>>
>> cheers,
>>
>> Thomas
>>
>>
>>
>>
>>
>> On 15.06.23 11:01, Bastien TEINTURIER wrote:
>> > Hi Thomas,
>> >
>> > First of all,
paying for the
common transaction fields only once instead of N times (where N is the
size of the batch). For larger batches, in a high-fee future, I believe
this could be significant?
Thanks,
Bastien
Le mar. 24 oct. 2023 à 06:41, David A. Harding a écrit :
> On 2023-10-17 03:03, Bastien TEINT
ed the reserve for our users in Bitkit (well, down to the
> dust limit because it doesn't work currently without it).
>
> I think this behaviour could/should be fixed, have you already reported
> the issue?
>
> Cheers,
> ziggie
>
> --- Original Message ---
>
gt; and its companion nversion=3 policy, where an attacker package RBF a
>> honest package out of the
>> > mempool to subsequently double-spend its own high-fee child with a
>> transaction unrelated to the
>> > channel. As the remaining commitment transaction is pre-signed with a
>> m
itments, forwarding HTLCs and also
> finding routes?
>
> -kp
>
> --- Original Message ---
> On Wednesday, October 18th, 2023 at 3:51 PM, Bastien TEINTURIER <
> bast...@acinq.fr> wrote:
>
> Good morning list,
>
> I'd like to discuss the channel reserve re
he exchange does not have an incentive to
> double-spend its own withdrawal transactions, or if all the batched funding
> outputs are shared with a LSP, malicious collusion is less plausible.
>
> Best,
> Antoine
>
> Le mer. 18 oct. 2023 à 15:35, Bastien TEINTURIER a
> écrit :
gt; now but still keep the dust reserve.
>
> Tony Giorgio
>
>
>
>
>
> Original Message
> On Oct 18, 2023, 8:51 AM, Bastien TEINTURIER < bast...@acinq.fr> wrote:
>
>
> Good morning list,
>
> I'd like to discuss the channel reserve requirement, and arg
;
> https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf
>
> Appreciated expert eyes of folks understanding both lightning and core
> mempool on this.
> There was a lot of back and forth on nversion=3 design rules, though the
> test is normally built on
Good morning list,
I'd like to discuss the channel reserve requirement, and argue that it
should be fine to get rid of it for channels between mobile wallet users
and their service provider. I know, I know, your first reaction will be
"but this is a security parameter, I don't want to hear about
Good morning list,
I've been trying to design a protocol to let users withdraw funds from
exchanges directly into their lightning wallet in an efficient way
(with the smallest on-chain footprint possible).
I've come to the conclusion that this is only possible with some form of
covenants (e.g.
ty to how we
> can deliver the commands. Functionally they are very similar however.
>
> Cheers,
> Christian
>
> On Thu, Sep 7, 2023, 15:06 Bastien TEINTURIER wrote:
>
>> Hi William,
>>
>> > What is wrong with runes/macaroons for validating and authenticating
>
alidate it manually. Also, this is fully configurable: you can
choose which RPCs you want to protect that way and which RPCs you want
to keep open.
Thanks,
Bastien
Le mer. 6 sept. 2023 à 17:42, William Casarin a écrit :
>
> On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER w
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Tuesday, September 5th, 2023 at 5:26 PM, Bastien TEINTURIER <
bast...@acinq.fr> wrote:
>
>
> > Good morning list,
> >
> > I have just opened a PR to the bLIPs repository [1
Good morning list,
I have just opened a PR to the bLIPs repository [1] to document an idea
that I started investigating a long time ago and had already discussed
with a few people, but never found the time to write it up before.
This is a very simple architecture to securely send administrative
Hey Matt,
Great work on finding this issue, thoroughly testing it against
implementations,
and on the follow-up you did after reporting this to the various teams.
We all agree that having more people spending time poking at the code
to find issues is very beneficial for the project. I hope your
Hi ghost,
> Note that the "reputation loss" argument does not hold up that well if
> you let Bob connect to arbitrary nodes.
That's true, in that case such nodes don't care as much about their
reputation and could have an incentive to cheat. But even in that
case, the user will detect it easily
Hi Thomas,
> That's a pity. I would have expected you to be interested, given that
> Phoenix could benefit from that feature.
I don't think this is an attack wallet providers can reasonably attempt.
The mobile wallet can check at every connection that the provider isn't
trying to cheat, and the
he non-trivial part is to design
the proof that the user could share publicly, without revealing its
private data or leaking its backup encryption keys.
Thanks,
Bastien
Le mer. 16 août 2023 à 15:16, Peter Todd a écrit :
> On Wed, Aug 16, 2023 at 09:56:21AM +0200, Bastien TEINTURIER wrote:
>
Hi Thomas,
I don't think those fraud proofs are necessary at all. They're also
dangerous, because they impose a hard penalty on LSPs for something
that should be best effort (and could get desynchronized by connection
issues, especially with flaky mobile connections).
I agree with Peter Todd
tacks, unannounced channel assumptions,
LSPs, and the strict enforcement of many hops being included in the blinded
part of the route.
>
> Tony
>
> On 7/27/23 02:20, Bastien TEINTURIER wrote:
>
> Hey,
>
> > This breaks down since we have pretty weak anti-correlation mechanisms
that a user is much closer to one of
> them without realizing. A sender might try to go for 6 hops, but if it
> turns out that their first hop is one of the nodes in the blinded route, it
> ruins the privacy they were trying to attain. PTLCs could help, but there's
> still timing and amou
Hey Ben,
I'm not sure why it would be dramatically different from today. If I
understand your scenario correctly, the recipient would only provide
blinded paths that go through "regulated" nodes so that they can
witness the payment. Since the recipient agrees on doing that, the
recipient could
Hey Zman,
I'm a bit confused because you use a different mechanism than the one
specified in the latest schnorr multi-hop locks proposal that I know of,
which can be found in [1].
If we use the construction from [1], it seems straightforward that using
trampoline doesn't have any impact on the
Hi Thomas,
> I believe pre-payment of the mining fee can be combined with 0-conf;
> I am not sure why you picture them as opposed? Even with BOLT-12, I
> don't see 0-conf going away.
Sorry if that was unclear, that's not at all what I meant. What I meant
is that if we *stopped* using 0-conf for
Hi Thomas,
First of all, I'd like to highlight something that may not be obvious
from your email, and is actually pretty important: your proposal
requires *senders* to be aware that the payment will lead to a channel
creation (or a splice) on the *receiver* end. In particular, it requires
all
some worst-case liquidity griefing scenario. A privacy-preserving
> credential can be introduced between the payment of the fee and the redeem
> of the service to unlink dual-funding initiators (if the maker has enough
> volume to constitute a reasonable anonymity set).
>
> Best,
> Antoi
r us in this case).
> > 3) After tx_complete exchange, TryLock() our UTXO inputs and abort if
> > already locked.
> > 4) Broadcast funding transaction and begin using the 0-conf channel.
> >
> > I think this at least enables the common use case for 0-conf: LSPs can
> >
Good morning list,
One of the challenges created by the introduction of dual funded
transactions [1] in lightning is how to protect against liquidity
griefing attacks from malicious peers [2].
Let's start by reviewing this liquidity griefing issue. The dual funding
protocol starts by exchanging
Hi Dustin,
I believe this is the scenario I described in [1]?
I haven't looked at the `announcement_signatures` case yet, but at least
for the `commit_sig` case this should never be an issue. It only means
that sometimes, after sending `splice_locked`, you will receive some
`commit_sig` messages
Good morning list,
As some of you may know, we've been hard at work experimenting with
splicing [1]. Splicing is a complex feature with a large design space.
It was interesting to iterate on two separate implementations (eclair
and cln) and discover the pain points, edge cases and things that
e restrictive solution to
> what's already possible: being able to dynamically fee bump commitment
> transactions, and aggregate second level spends.
>
> -- Laolu
>
> On Thu, Oct 27, 2022 at 6:51 AM Bastien TEINTURIER
wrote:
>>
>> Good morning list,
>>
&g
critical in the current environment. However,
> if we eventually get to the point where the blockchain is highly-contested
> and fees are high, it may no longer be worth paying the fees to put a splice
> transaction on-chain unless a large amount of capital is at stake for a long
> p
Good morning list,
The lightning network transaction format was updated to leverage CPFP
carve-out and allow nodes to set fees at broadcast time, using a feature
called anchor outputs [1].
While desirable, this change brought a whole new set of challenges, by
requiring nodes to maintain a
Hi John,
> My understanding of the current Lightning protocol is that users specify
a to_self_delay safety parameter which is typically about 2 weeks and that
they pay for routing, but not for their partner's cost-of-capital. Is that
correct?
>
> If it is, then when a dedicated user (DLU)
Hi Joost,
I need more time to review your proposed change, but I wanted to quickly
correct a misunderstanding you had in quoting eclair's code:
> Unfortunately it is possible for nodes on the route to hide themselves.
> If they return random data as the failure message, the sender won't know
>
Hey John,
Thanks for sharing, this is very interesting.
There is a good insight here that we can remove the intermediate
HTLC-timeout transaction for outgoing payments because we are the
origin of that payment (and thus don't need to quickly claim the
HTLC on-chain to then relay that failure to
Hey all,
Thanks for the comments!
Here are a few answers inline to some points that aren't fully addressed
yet.
@laolu
> Another question on my mind is: if this works really well for rate
limiting of
> onion messages, then why can't we use it for HTLCs as well?
Because HTLC DoS is
gt; increases on that incoming channel. My money gets locked up in a channel
>> that may or may not be interesting to me. Wouldn't it be fair to be
>> compensated for that?
>>
>> Any thoughts from routing node operators would be welcome too (or links
>> to previous th
Hi Joost,
As I've already stated every time this has been previously discussed, I
believe
this doesn't make any sense. The funds that are on the other side of the
channel belong to your peer, not you, so they're free to use it however they
want. If you're not happy with the way your peer is
me network can be _both_ a reliable
> > micro-payment system _and_ also a reliable arbitrary message transport
> > layer. I guess only time will tell...
> >
> > > The `shared_secret_hash` field contains a BIP 340 tagged hash
> >
> > Any reason to use the tagg
During the recent Oakland Dev Summit, some lightning engineers got
together to discuss DoS
protection for onion messages. Rusty proposed a very simple
rate-limiting scheme that
statistically propagates back to the correct sender, which we describe
in details below.
You can also read this in gist
Hey Zman and list,
I don't think waxwing's proposal will help us for private gossip.
The rate-limiting it provides doesn't seem to be enough in our case.
The proposal rate-limits token issuance to once every N blocks where
N is the age of the utxo to which we prove ownership of. Once the token
is
I completely agree with Matt, these two components are completely
independent
and too often conflated. Scoring channels and estimating liquidity is
something
that has been regularly discussed by implementations for the last few years,
where every implementation did its own experiments over time.
Good morning list,
I will describe here a vulnerability found in older versions of some
lightning implementations of anchor outputs. As most implementations
have not yet released support for anchor outputs, they should verify
that they are not impacted by this type of vulnerability while they
Good morning Alex,
I’ve been investigating set reconciliation as a means to reduce bandwidth
and redundancy of gossip message propagation.
>
Cool project, glad to see someone working on it! The main difficulty here
will
indeed be to ensure that the number of differences between sets is bounded.
Good morning list,
In the last couple of months, @thomash-acinq and I have spent a lot of time
working on route blinding for payments [1]. As you may know, route blinding
is a prerequisite for onion messages [2] and Bolt 12 offers [3].
Using route blinding to provide anonymity for onion messages
Le mar. 21 déc. 2021 à 17:04, Anthony Towns a écrit :
> On Tue, Dec 21, 2021 at 04:25:41PM +0100, Bastien TEINTURIER wrote:
> > The reason we have "toxic waste" with HTLCs is because we commit to the
> > payment_hash directly inside the transaction scripts, so we
Good morning,
I agree, this onion message trick could let us work around this kind of
cheating
attempt. However, it becomes quite a complex protocol, and it's likely that
the more we progress towards specifying it, the more subtle issues we will
find that will require making it even more complex.
Good morning,
Thanks for looking into this!
I believe there is another limitation that you're not mentioning: it's
easy for a malicious node to blame an honest node. I'm afraid this is a
serious limitation of the proposal.
If we have a payment: A -> B -> C -> D and C is malicious.
C can forward
0], people jumping on the thread now may find it
helpful to better understand this discussion.
Thanks,
Bastien
[0] https://github.com/t-bast/lightning-docs/pull/16
Le mer. 8 déc. 2021 à 11:00, Bastien TEINTURIER a écrit :
> Hi AJ,
>
> I think the problem t-bast describes comes up here as well wh
Hi AJ,
I think the problem t-bast describes comes up here as well when you
> collapse the fast-forwards (or, anytime you update the commitment
> transaction even if you don't collapse them).
Yes, exactly.
I think doing a synchronous update of commitments to the channel state,
> something like:
Hi Z,
`SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four
> years?) or a similar "covenant" opcode,
such as `OP_CHECKTEMPLATEVERIFY` without any commitments or an
> `OP_CHECKSIGFROMSTACK` on an empty message.
> All you really need is a signature for an empty message, really...
>
Hi Jeremy,
Right now, lightning anchor outputs use a 330 sats amount. Each commitment
transaction has two such outputs, and only one of them is spent to help the
transaction get confirmed, so the other stays there and bloats the utxo set.
We allow anyone to spend them after a csv of 16 blocks, in
Hi Z, Lloyd,
Let's ignore the musig nonce exchanges for now. I believe these can be
easily included in existing messages: they probably aren't the reason we
need more round-trips (at least not the one I'm concerned about for now).
Basically, if my memory and understanding are accurate, in the
Good morning list,
There was a great recent post on the mailing list detailing how we could
do PTLCs on lightning with a lot of other goodies [0]. This proposal
contained heavy changes to the transaction structure and the update
protocol. While it's certainly something we'll want to do in the
Hi Matt,
I like this proposal, it's a net improvement compared to hodling HTLCs
at the recipient's LSP. With onion messages, we do have all the tools we
need to build this. I don't think we can do much better than that anyway
if we want to keep payments fully non-custodial. This will be combined
Hi,
This is exactly what the dual funding proposal provides:
https://github.com/lightningnetwork/lightning-rfc/pull/851
Cheers,
Bastien
Le mer. 22 sept. 2021 à 07:29, Ole Henrik Skogstrøm
a écrit :
> Hi
>
> I have found a way of opening balanced channels using LND's psbt option
> when opening
Hi Joost,
Concept ACK, I had toyed with something similar a while ago, but I hadn't
realized
that invoice storage was such a DoS vector for merchants/hubs and wasn't
sure it
would be useful.
Do you have an example of what information you would usually put in your
`encoded_order_details`?
I'd
Good morning list,
I've been mulling over some limitations of our feature bits mechanism and
I'm interested in your ideas and comments.
Our feature bits mechanism works well for symmetric features (where both
peers play the same role) but not so well for asymmetric features (where
there is a
ame bit, and they may never really intersect depending on the
> nature or how widespread the new feature is.
>
> It's also likely the case that already implementations, or typically forks
> of implementations are already using "undocumented" TLVs or feature bits in
> the wil
Thanks for starting that discussion.
In my opinion, what we're really trying to address here are the two
following
points (at least from the point of view of someone who works on the spec and
an implementation):
- Implementers get frustrated when they've worked on something that they
think
is
er. 30 juin 2021 à 02:09, Rusty Russell a
écrit :
> Bastien TEINTURIER writes:
> > Hi Rusty,
> >
> > On the eclair side, we instead send `funding_locked` as soon as we
> > see the funding tx in the mempool.
> >
> > But I think your proposal would work as we
Hi Rusty,
On the eclair side, we instead send `funding_locked` as soon as we
see the funding tx in the mempool.
But I think your proposal would work as well.
We may want to defer sending `announcement_signatures` until
after the funding tx has been confirmed? What `min_depth` should
we use
the limit).
Bastien
Le sam. 24 avr. 2021 à 10:01, Bastien TEINTURIER a
écrit :
> You're right, I was thinking about trimmed HTLCs (which can re-appear in
> the commit tx
> if you lower the feerate via update_fee).
>
> Dust HTLCs will never appear in the commit tx regardless of subse
a
écrit :
> The update_fee message does not, as far as I recall, change the dust limit
> for outputs in a channel (though I’ve suggested making such a change).
>
> On Apr 23, 2021, at 12:24, Bastien TEINTURIER wrote:
>
>
> Hi Eugene,
>
> The reason dust HTLCs c
Hi Eugene,
The reason dust HTLCs count for the 483 HTLC limit is because of
`update_fee`.
If you don't count them and exceed the 483 HTLC limit, you can't lower the
fee anymore
because some HTLCs that were previously dust won't be dust anymore and you
may end
up with more than 483 HTLC outputs in
Great idea, I'll join as well.
Thanks for setting this in motion.
Le ven. 23 avr. 2021 à 17:39, Antoine Riard a
écrit :
> Hi Jeremy,
>
> Yes dates are floating for now. After Bitcoin 2021, sounds a good idea.
>
> Awesome, I'll be really interested to review again an improved version of
>
Good morning list,
Before we close this amazing year, I wanted to give you an update and reboot
excitement around trampoline routing for 2021.
Acinq has been running a trampoline node for more than a year to provide
simple
and reliable payments for tens of thousands of Phoenix [1] users. We've
Good morning list,
This is an interesting approach to solve this problem, I really like the
idea.
It definitely deserves digging more into it: the fact that it doesn't add
an additional
payment makes it largely superior to upfront payment schemes in terms of UX.
If we restrict these stake
Hey Rusty,
Good questions.
I think we could use additive tweaks, and they are indeed faster so it can
be worth doing.
We would replace `B(i) = HMAC256("blinded_node_id", ss(i)) * P(i)` by `B(i)
= HMAC256("blinded_node_id", ss(i)) * G + P(i)`.
Intuitively since the private key of the tweak comes
Good morning Joost and Z,
So in your proposal, an htlc that is received by a routing node has the
> following properties:
> * htlc amount
> * forward up-front payment (anti-spam)
> * backward up-front payment (anti-hold)
> * grace period
> The routing node forwards this to the next hop with
> *
Hey Joost and Z,
I brought up the question about the amounts because it could be that
> amounts high enough to thwart attacks are too high for honest users or
> certain uses.
I don't think this is a concern for this proposal, unless there's an attack
vector I missed.
The reason I claim that is
Thanks for your answers,
My first instinct is that additional complications are worse in general.
> However, it looks like simpler solutions are truly not enough, so adding
> the complication may very well be necessary.
I agree with both these statements ;). I'd love to find a simpler solution,
Good morning list,
Sorry in advance for the lengthy email, but I think it's worth detailing my
hybrid proposal
(bidirectional upfront payments), it feels to me like a workable solution
that builds on
previous proposals. You can safely ignore the details at the end of the
email and focus only on
Good morning list,
I've started summarizing proposals, attacks and threat models on github [1].
I'm hoping it will help readers get up-to-speed and avoid falling in the
same pitfalls we already
fell into with previous proposals.
I've kept it very high-level for now; we can add nitty-gritty
To be honest the current protocol can be hard to grasp at first (mostly
because it's hard to reason
about two commit txs being constantly out of sync), but from an
implementation's point of view I'm
not sure your proposals are simpler.
One of the benefits of the current HTLC state machine is that
Hey laolu,
I think this fits in nicely with the "parameter re-negotiation" portion of
> my
> loose Dynamic commitments proposal.
Yes, maybe it's better to not offer two mechanisms and wait for dynamic
commitments to offer that
flexibility.
Instead, you may
> want to only allow them to utilize
ot;fully loaded" commitment
> transaction.
> Even with HTLCs, they could only be signed at 1 sat/byte from the funder's
> perspective, once again putting the burden on the broadcaster/confirmer to
> make up the difference.
>
> -- Laolu
>
>
> On Mon, Oct 5, 2020 at 6
Good morning,
For instance, Tor is basically two-layer: there is a lower-level TCP/IP
> layer where packets are sent out to specific nodes on the network and this
> layer is completely open about where the packet should go, but there is a
> higher layer where onion routing between nodes is used.
Hey Zman,
raising the minimum payment size is another headache
>
It's true that it may (depending on the algorithm) lower the success rate
of MPP-split.
But it's already a parameter that node operators can configure at will (at
channel creation time),
so IMO it's a complexity we have to deal
t should cost higher for the counterparty
> to withhold a HTLC than paying onchain-fees to close the channel.
>
> Or can you think about another mitigation for the issue raised above ?
>
> Antoine
>
> Le lun. 5 oct. 2020 à 09:13, Bastien TEINTURIER via Lightning-dev &l
Good morning Antoine and Zman,
Thanks for your answers!
I was thinking dynamic policy adjustment would be covered by the dynamic
> commitment mechanism proposed by Laolu
I didn't mention this as I think we still have a long-ish way to go before
dynamic commitments
are spec-ed, implemented and
If I remember correctly, it looks very similar to how I2P establishes
tunnels, it may be worth
diving in their documentation to fish for ideas.
However in their case the goal is to establish a long-lived tunnel, which
is why it's ok to have
a slow and costly protocol. It feels to me that for
Hi darosior,
This is true, but we haven't solved yet how to estimate a good enough
`min_relay_fee` that works
for end-to-end tx propagation over the network.
We've discussed this during the last two spec meetings, but it's still
unclear whether we'll be able to solve
this before package-relay
1 - 100 of 141 matches
Mail list logo
