Hi John,
While the idea of using sliding reaction window for blockchain congestion
detection has been present in the "smart contract" space at large [0] and
this has been discussed informally among Lightning devs and covenant
designers few times [1] [2], this is the first and best formalization
re what you mean here, could you elaborate?
>
> > I wonder if in a PTLC world, you can generate an aggregate curve point
> for all the sub combinations of scalar plausible. Unrevealed curve points
> in a taproot branch are cheap. It might claim an offered HTLC near-constant
> size too.
&
Hi Johan,
Few comments.
## Transaction recycling
The transaction recycling attack is made possible by the change made
to HTLC second level transactions for the anchor channel type[8];
making it possible to add fees to the transaction by adding inputs
without violating the signature. For the
> IIRC correctly, in your scenario, you're dealing with Carol -> Bob ->
Alice.
> Mallory can only replace an HTLC-timeout transaction if she's directly
> connected with the peer she's targeting via a direct channel. She cannot
> unilaterally replace any transaction in the mempool solely with
ther wormhole of technical
issues).
Best,
Antoine
[0] See The Ugly scenario here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018011.html
Le dim. 22 oct. 2023 à 03:27, Antoine Riard a
écrit :
> Hi,
>
> I think if Gleb Naumenko and myself allocate our research time on t
quot;do you have a non-null
chance to mine a block as long as a HTLC-output is committed on an
off-chain state only known among off-chain counterparties e.g".
Le mar. 14 nov. 2023 à 19:50, Peter Todd a écrit :
> On Mon, Nov 13, 2023 at 02:18:16AM +, Antoine Riard wrote:
> > Your two lates
Your two latest mails.
> The problem that OP_Expire aims to solve is the fact that Carol could
prevent
> Bob from learning about the preimage in time, while still getting a
chance to
> use the preimage herself. OP_Expire thoroughly solves that problem by
ensuring
> that the preimage is either
Hi Zeeman,
> Neither can Bob replace-recycle out the commitment transaction itself,
because the commitment transaction is a single-input transaction, whose
sole input requires a signature from
> Bob and a signature from Carol --- obviously Carol will not cooperate on
an attack on herself.
The
ter Todd a écrit :
> On Fri, Nov 03, 2023 at 05:25:24AM +, Antoine Riard wrote:
> > > To be clear, are you talking about anchor channels or non-anchor
> channels?
> > > Because in anchor channels, all outputs other than the anchor outputs
> > provided
> > >
come as strong changes in lightning sec model and economic efficiency.
Good to hold one's commitment in the face of up and down.
Best,
Antoine
Le ven. 23 juin 2023 à 10:39, Antoine Riard a
écrit :
> Hi lightning devs,
>
> Proposing myself to organize next year's LN Summit
fees
pre-signed states and adjust in consequence the CPFP paid, and then evict
out the bumping CPFP.
Le jeu. 2 nov. 2023 à 17:07, Matt Morehouse a
écrit :
> On Thu, Nov 2, 2023 at 6:27 AM Peter Todd via bitcoin-dev
> wrote:
> >
> > On Thu, Nov 02, 2023 at 05:24:36AM +, An
u, Nov 02, 2023 at 05:24:36AM +, Antoine Riard wrote:
> > Hi Peter,
> >
> > > So, why can't we make the HTLC-preimage path expire? Traditionally,
> we've
> > tried
> > > to ensure that transactions - once valid - remain valid forever. We do
> > this
&
5:57:36PM +0100, Antoine Riard via bitcoin-dev
> wrote:
> > Here enter a replacement cycling attack. A malicious channel counterparty
> > can broadcast its HTLC-preimage transaction with a higher absolute fee
> and
> > higher feerate than the honest HTLC-timeout of the
ng players are concealing
massive security risks from the average end-user, and in the occurrence of
the risks flagrant realization will deny any form of accountability by
walls of PR statements.
Le sam. 21 oct. 2023 à 21:05, Antoine Riard a
écrit :
> Hi,
>
> As I've been shown offline
ated" is a good read.
[4] While my former employer, Chaincode Labs, paid for my english lessons
back in 2020. Generally it was a good insight from them to train people on
how to communicate in a crisis.
Le ven. 20 oct. 2023 à 07:56, Antoine Riard a
écrit :
> Hi,
>
> After
Hi,
I think if Gleb Naumenko and myself allocate our research time on this
issue, we should (hopefully) be able to come with a strong sustainable fix
to the lightning network, both systematically solving pinnings and
replacement cycling attacks (and maybe other mempools issues or things
related
nsactions can be let
floating in network mempools).
Best,
Antoine
Le jeu. 19 oct. 2023 à 18:54, Matt Morehouse a
écrit :
> On Thu, Oct 19, 2023 at 5:22 PM Antoine Riard
> wrote:
> >
> > Hi Matt,
> >
> > This mitigation is mentioned in the attached paper (see subsection 3
material has been published and other experts are
available. Then I'll be back focusing more on bitcoin core.
Best,
Antoine
Le lun. 16 oct. 2023 à 17:57, Antoine Riard a
écrit :
> (cross-posting mempool issues identified are exposing lightning chan to
> loss of funds risks, other multi
s and strange behavior. Its possible that these mitigations might,
> by some stroke of luck,
> > happen to catch such an attack and prevent it, because something took
> longer than the attacker
> > intended or whatever. But, that's a far cry from any kind of material
> &quo
t; this is a "standard" transaction that should use a reasonable feerate
> and nVersion=2, that's why I don't think this comment applies.
>
> Cheers,
> Bastien
>
> Le mer. 18 oct. 2023 à 20:04, Antoine Riard a
> écrit :
>
>> Hi Bastien,
>>
>>
is quite different from the standard replacement
> cycling attack, because in this protocol wallet users can only
> unilaterally double-spend with a commit tx, on which they cannot set
> the feerate. The only participant that can "easily" double-spend is
> the exchange, and they woul
Hi Bastien,
> The naive way of enabling lightning withdrawals is to make the user
> provide a lightning invoice that the exchange pays over lightning. The
> issue is that in most cases, this simply shifts the burden of making an
> on-chain transaction to the user's wallet provider: if the user
ended or whatever. But, that's a far cry from any kind of material
> "fix" for the issue.
>
> Ultimately the only fix for this issue will be when miners keep a history
> of transactions they've
> seen and try them again after they may be able to enter the mempool
> because
s is I think
restrained to people listed on the disclosure mails _and_ we had other
pendings non-disclosed security issues at the time like the ones revealed
"fake channel DoS vector" the 23th August 2023, we didn't conduct them.
Le mar. 17 oct. 2023 à 18:47, Antoine Riard a
é
Hi Zeeman,
> At block height 100, `B` notices the `B->C` HTLC timelock is expired
without `C` having claimed it, so `B` forces the `BC` channel onchain.
> However, onchain feerates have risen and the commitment transaction and
HTLC-timeout transaction do not confirm.
This is not that the
r node runners to restrict
> the amount and number of HTLCs for big channels to unknown peers. It
> quickly comes with a loss when the HTLCs the attacker tries to steal are
> small.
>
>
> Kind regards,
>
> ziggie
>
>
> --- Original Message ---
> On Monday, Oc
(cross-posting mempool issues identified are exposing lightning chan to
loss of funds risks, other multi-party bitcoin apps might be affected)
Hi,
End of last year (December 2022), amid technical discussions on eltoo
payment channels and incentives compatibility of the mempool anti-DoS
rules, a
Hi John,
Thanks for the additional insightful comments. See new questions at the end.
> "My main point is that there's a huge pool of potential users that just
want payments to work, and they don't want to devote time or hardware
resources to making them work (if they can away with that)"
Sure,
Hi John,
Thanks for the proposal, few feedback after a first look.
> If Bitcoin and Lightning are to become widely-used, they will have to be
> adopted by casual users who want to send and receive bitcoin, but > who do
> not want to go to any effort in order to provide the infrastructure for
Hi Rene,
> In their technical document [1] they mention that their new patch cannot
defend against a large botnet and suggest that anonymous credentials [2]
among other techniques should be investigated.
>From my memory, mitigating channel jamming with dynamic proof-of-work (e.g
bip154) was
tion so far.
In the meantime, there are only 144 blocks in a day (on average) and I have
package relay and mempool to review in Bitcoin Core to improve Lightning
for all, further discussions won't be constructive and I won't reply
further.
Best,
Antoine
Le dim. 27 août 2023 à 19:00, M
e who hasn't spent
> much time contributing to LDK over the past two or three years, stop
> trying to speak on behalf of
> the LDK project.
>
> Thanks,
> Matt
>
> On 8/24/23 4:33 PM, Antoine Riard wrote:
> > Hi Matt,
> >
> > Thanks for the great work her
Hi Matt,
Thanks for the great work here.
Confirming the v0.0.114 release number for the LDK "fake" lightning
channels mitigations.
>From the LDK-side, the vulnerability didn't come as novel knowledge, we
have thought of potential DoS issues in peer state machine handling (e.g
[0]) a long time
21 août 2023 à 12:07, Peter Todd a écrit :
> On Sat, Aug 19, 2023 at 12:02:39AM +0100, Antoine Riard wrote:
> > As a backup plan, I think we could consider countries like Morocco or
> > Algeria, which given current composition of the organization committee is
> > straightforward
conference and meeting lots of folks using Bitcoin and developing on
> top of it who I can't
> meet elsewhere, I'd weigh the costs differently.
>
> Matt
>
> On 8/20/23 6:40 PM, Antoine Riard wrote:
> > Hi Matt,
> >
> > I fully understand the concern about th
s being hosted.
>
> Matt
>
> On 8/18/23 4:02 PM, Antoine Riard wrote:
> > Hi lightning devs,
> >
> > Follow up on next year LN Summit organization:
> >
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-June/003994.html
> > <
> https:/
boundaries to
plan well ahead and start small.
Cheers,
Antoine
[0] https://www.afrobitcoin.org
[1] https://adoptingbitcoin.org/capetown-2024/
[2] https://coredev.tech/pastevents.html
Le ven. 23 juin 2023 à 10:39, Antoine Riard a
écrit :
> Hi lightning devs,
>
> Proposing myself to orga
Hi Ben,
On the technical aspects of blinding paths, in the context of CivKit
(large-scale peer-to-peer electronic market system), blinded paths could be
used by market board themselves to request than makers and takers are going
through the lightning node associated with the board to conclude a
Hi Zeeman,
> A proposal I made in the Signal group after the summit would be to not
use MuSig2 signing for commitment transactions (== unilateral closes).
> Instead, we add a tapscript branch that is just ` OP_CHECKSIGVERIFY
OP_CHECKSIG` and use that for unilateral closes.
> We only sign with
Hi Zeeman,
On the buffering of BOLT8 message in the equalizing-packet interface
object, I think implementations should be careful of flushing them at fixed
intervals, otherwise you might have issues like an `update_fulfill_htlc`
not being back on time and the channel counterparty unilaterally
Hi,
> The only damage we can observe in the protocol is routing fees. If we go
ahead with our suggestion, it will be straightforward to choose a different
threshold based on the preference of a node. We have some suggestions for
receiving nodes, for example.
I think there is another obvious
the list at
> > lightning-dev-ow...@lists.linuxfoundation.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Lightning-dev digest..."
> >
> >
> > Today's Topics:
> >
> > 1. LN Summi
Hi lightning devs,
Proposing myself to organize next year's LN Summit in Africa, with a rough
date somewhere in June 2024.
There are a lot of reasons to hold a summit there. Africa is a beautiful
continent, there is a rich cultural and historical past, a lot of
fragmentation in the financial
Hi calle,
Thanks for the report.
>From my understanding of what you're describing, the attack is possible
because LNBits backend does not check that an external received HTLC
`amount_msat` satisfies the invoice amount for both matching preimage and
payment secret. This sounds plausible to me.
Hi,
> Bob can also forward but not endorse Alice's HTLC. All of this is a
function of how much credit Bob gives to Alice's judgment. In case of
jamming, the damage that Alice inflicts should be proportional to the
revenue she recently created for Bob, and so the more damage, the higher
the
Hi Bastien,
> This can be fixed by using a "soft lock" when selecting utxos for a non
> 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> utxos while non 0-conf funding attempts can (should) reuse soft locked
> utxos.
If my understanding of the "soft lock" strategy is
> I think it's important to differentiate between fees a node charges and
> *reputation_revenue*. Reputation is determined as a function of the latter.
> If Caroll has a very high *reputation_revenue* and Bob has a very low one,
> then Bob probably won't have a high reputation with Caroll, as the
Hi list,
As it has been discussed before, a solution to mitigate jamming
attacks over the Lightning Network consists in the introduction of
credentials that must be acquired by HTLC senders to lock each hop
liquidity along the forwarding path. Those credentials can be
privacy-preserving to mask
Hi all,
> That is, one cannot gain reputation during low fee times and use it when
fees are high.
> Good reputation is also a function of the general environment, and so if
there is a fee spike, reputation will change. It is true that nodes can go
rogue, but this is why we aim > for the price of
Hi Tony,
> Is there a better place to have public communication? Unfortunately since
one off topic email was sent here, it's been a ghost town. It appears that
there's many emails being held and only one moderator that checks them once
a week.
As I think you're referring to my post of March 21th
Hi *,
> Our suggestion is to start simple with a binary endorsement field. As
> we learn more, we will be better equipped to understand whether a
> more expressive value is required.
I think the HTLC endorsement scheme as proposed is still suffering from a
vulnerability as local reputation can
Hi Bastien,
Thanks for the update on the state of splicing.
> We've also discovered that implementing 0-conf splicing is tricky: you
> need to be very careful about scenarios where your peer force-closes
> using an *inactive* commitment that ends up double-spending what you
> think is the only
acting the wider
non-LL Taro community).
There are 2 more troubling issues. One, the title of the letter "Chaincode
Labs - Cease & Desist Letter to Antione Riard". I really received it like
this and checked the typo multiple times. I think my name is Antoine Riard,
I've to verify b
Hi all,
My understanding of the local reputation channel is the following, when Bob
receives a HTLC forwarding request from Alice to Caroll:
- if Alice has reputation of 1 and Alice endorses the transaction, Bob
forwards and endorses the HTLC to Caroll
- else if the HTLC amount is under the
Hi Val,
Thanks for the proposal here. About using OM for payment probing, I think
there could be an alternative of the routing hops themselves announcing
their liquidity balances with an extension or new set of gossip messages.
Gossips messages could commit to a liquidity balance and duration
As long as protocol development and design is done neutrally, I'm all fine!
Le ven. 17 févr. 2023 à 10:48, Joost Jager a écrit :
> Right, that was my above point about fetching scoring data - there's three
>> relevant "buckets" of
>> nodes, I think - (a) large nodes sending lots of payments,
Yeah definitely looking forward to talk more about highly available
lightning channels. During next LN channel jamming meetup! .
Le jeu. 16 févr. 2023 à 00:43, Matt Corallo a
écrit :
>
>
> On 2/14/23 11:36 PM, Joost Jager wrote:
> > But how do you decide to set it without a credit
Hi Joost,
> For a long time I've held the expectation that eventually payers on the
lightning network will become very strict about node performance. That they
will > require a routing node to operate flawlessly or else apply a hefty
penalty such as completely avoiding the node for an extended
Hi Clara,
> * They will likely require a network wide upgrade: when a sender
>makes a payment, the full path will need to understand the new
>feature bit for it to be used.
I believe the upgradeability dimension is different both for circuit breaker
and staking credentials --
(Reply 2/2)
> * Whether we should look into a more complicated approach that
>includes a "proof of forward" secret in the next node's onion which
>must be supplied to claim the upfront fee.
One of the hard things with a "proof of forward" is a hop colluding with
the next counterparty
Hi Clara,
(Reply 1/2 - Apparently there is a limit of 80KB on Lightning mailing post)
> * They will likely require a network wide upgrade: when a sender
>makes a payment, the full path will need to understand the new
>feature bit for it to be used.
I believe the upgradeability
Hi all,
Since starting to hack on LDK, I’ve been interested in running some
components of a Lightning node in a dedicated hardware environment, in the
image of what is done by the smart card industry. We have been doing a
bunch of refactoring in that sense early on to isolate our signing
Hi LN devs,
Following the November proposal of mitigating channel jamming with
Reputation Credentials, started to document the protocol architecture.
After feedback on the naming protocol itself, I switched to Staking
Credentials. In fact the proposed architecture enables mitigations
deployment
ntity.
Still, I think eltoo channels would simplify the implementation of
distributed towers by Lightning implementation, notably handling concurrent
broadcast w.r.t chain asynchronicity issues, and hopefully removing the
concern of commitment transaction key duplication by tower [0].
Bes
ransaction is only allowed
> a single ephemeral anchor which is attached but not committed to by the
> SIGHASH_SINGLE|APOAS signature. This results in a 1-input-2-output
> transaction that isn't malleable. If and when we figure out how to un-pin
> these kinds of transactions, this poli
nt relies here. AFAICT, if there is an unbounded spending path
cycle introduced for one of the counterparties, you're exposed to "eltoo
states overflow".
Best,
Antoine
Le lun. 12 déc. 2022 à 22:51, Anthony Towns a écrit :
> On Mon, Dec 12, 2022 at 08:38:43PM -0500, Antoine Riard wrote:
all that matters. It does introduce a watchtower cycle, so it's
> not longer a one-shot architecture, or even k-shot exactly, it ends up
> looking like vanilla eltoo for that single path.
>
> Cheers,
> Greg
>
> On Thu, Dec 8, 2022 at 2:14 PM Antoine Riard
> wrote:
>
>
Hi list,
The following post describes a potential attack vector against eltoo-based
Lightning channels, from my understanding also including the recent
two-party eltoo w/ punishment construction. While I think this concern has
been known for a while among devs, and I believe it's mitigable by
Hi Clara,
Thanks for rolling the ball forward.
On the agenda, a few more thoughts.
> 1. Which parameters should be considered in reputation-based solutions?
I think before thinking about the parameters of reputation-based solutions,
we should discuss the security goal we're aiming to achieve
Hi AJ,
The eltoo irc channel is ##eltoo on Libera chat.
> - 2022-10-21, eltoo/chia:
https://twitter.com/bramcohen/status/1583122833932099585
On the eltoo/chia variant, from my (quick) understanding, the main
innovation aimed for is the limitation of the publication of eltoo states
more than
Hi Joost,
> The economic proportionality is that an attacker can't do much with a
> severely limited channel, and would need many more to achieve the same
> effect. I don't think it is possible to eliminate all bad behavior, and
> that the goal should just be to make it a lot harder than it
Hi Joost,
If I understand correctly circuitbreaker, it adds new "dynamic" HTLC slot
limits, in opposition to the "static" ones declared to your counterparty
during channel opening (within the protocol-limit of 483). On top, you can
rate-limit the HTLCs forwards based on the incoming source.
Hi Loki,
Thanks for raising awareness on this project.
I share the sentiment on the gradual generalization of Lightning onion
messaging as a transport network on its own for Bitcoin-specific traffic
such as offers, offline receive control flow or credentials tokens or even
in the future DLC
Hi Zeeman,
I think it is correct to say that if any mechanism to protect against
channel jamming succeeds, the remaining instance of apparent channel
jamming might be accidental. This rate of accident might be still high due
to spontaneous congestion (i.e more HTLC senders than slots/liquidity
Hi Dave & Zeeman,
As the credentials tokens should be blinded during countersigning and then
wrapped inside HTLC onions, the routing hops cannot use them to assign
blame. Instead the jamming attack prevention efficiency relies on
misbehaving senders exhausting their supply of scarce and costly
ations, is on by default in all those Lightning
> implementations etc. And even if it was I would want to opt out of it.
>
> Thanks
> Michael
>
> [0]: https://jamming-dev.github.io/book/
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: mi
.bitrated.com/faq
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> --- Original Message ---
> On Monday, November 21st, 2022 at 06:01, Antoine Riard <
> an
ike to mask).
Best,
Antoine
Le sam. 26 nov. 2022 à 15:48, David A. Harding a écrit :
> On 2022-11-21 14:26, Antoine Riard wrote:
> >> Clara Shikhelman wrote:
> >> 4. How would these tokens work with blinded paths and other
> >> privacy-preserving suggestions?
>
khelman
a écrit :
> Cool, thanks for that.
>
> Have you done any work on the economic aspects of the new tokens and their
> secondary markets?
>
> On Thu, Nov 24, 2022, 21:22 Antoine Riard wrote:
>
>> Hi Clara,
>>
>> The main benefit of this "staking"
unds like unconditional fees cover most of what this policy does,
> without the extra risks that come from creating a new token. Is there a
> clear benefit to using a token compared to unconditional fees and
> local reputation?
>
> Best,
> Clara
>
> On Wed, Nov 23, 2022
in detail, I think that some kind of
> recommended policy is needed. If presenting one is a low priority, and
> waiting for other things, my main concern is that it will just never happen
> ("any decade now" kind of situation).
>
> Best,
> Clara
>
> On Tue, No
Hi Clara,
Shared the mail on #lightning-dev Libera chat to get more feedback on
schedule.
> Do you have a timeline in mind for presenting such a policy?
See the comments on the BOLT #1043 PR, for now I'm thinking more to refine
the proposed credentials architectural framework.
I think dynamic
hannel?
> If this is the case, can't a routing node "trick" a user into buying many
> tokens and then bring the price up?
>
> 4. How would these tokens work with blinded paths and other
> privacy-preserving suggestions?
>
> Thanks again,
> Clara
>
> On Sun, Nov
Hi LN Devs,
tl;dr A formalization of a reputation-based scheme to solve channel jamming
is proposed. The system relies on "credentials" issued by routing hops and
requested to be attached to each HTLC forward request. The "credentials"
can be used by a reputation algorithm to reward/punish
Hi Clara, Sergei
Congrats for the paper!
Here are a few in-flight thoughts browsing the paper.
On introducing a general framework for evaluating attack mitigations, I
think this is relevant as scarce resources wastes, of which jamming is a
subcase is echoed multiple times not only in Lightning,
Hi Dustin,
>From my understanding, splice pinning is problematic for channel funds
safety. In the sense once you have a splice floating in network mempools
and your latest valid commitment transaction pre-signed fees isn't enough
to replace the splice, lack of confirmation might damage the claim
Hi Alex,
Let's say the adversary targeting your high-value "LiFi" infrastructure is
a nation-state sponsored hacking-group with strong capabilities (as we're
seeing today in the cryptocurrencies DeFi space). This hacking group avails
hundreds of bitcoins to fund channels, is able to setup
Gleb Naumenko and I would like to present our latest research on the
well-known channel jamming attacks affecting the Lightning Network. For a
reminder on the basis of channel jamming, we would like to point to Gleb's
earlier recollection [0].
We have a serie of research posts available here:
Hi Bastien,
Thanks for the proposal,
While I think establishing the rate limiting based on channel topology
should be effective to mitigate against DoS attackers, there is still a
concern that the damage inflicted might be beyond the channel cost. I.e, as
the onion messages routing is
Hi Laolu,
Thanks for the proposal, quick feedback.
> It *is* still the case that _ultimately_ the two transactions to close the
> old segwit v0 funding output, and re-open the channel with a new segwit v1
> funding output are unavoidable. However this adapter commitment lets peers
> _defer_
Hi Eugene,
> Since the remote party gives them a signature, after the timeout, the
offering party can
claim with the remote's signature + preimage, but can only spend with the
HTLC-timeout transaction because of SIGHASH_ALL.
I've not exercised the witness against our test framework though the
I've been informed by Mitre, the correct CVE assignment:
* c-lightning : CVE-2021-41592
* lnd: CVE-2021-41593
Not the assignement disclosed in the initial mail.
Le lun. 4 oct. 2021 à 11:09, Antoine Riard a
écrit :
> Hi,
>
> I'm writing a report to disclose specification-level vulner
13.3+ (CVE-2021-41592)
> > * LDK: v0.0.102 (not released as production software yet)
>
> * C-lightning v0.10.2 (CVE-2021-41593)
>
>
> Lisa
>
> On Mon, Oct 4, 2021 at 10:09 AM Antoine Riard
> wrote:
>
>> Hi,
>>
>> I'm writing a repo
ink we're already making that kind of social or economic assumption on
the user behavior w.r.t to full-node design. Blocks and transactions are
relayed for "free" today, not satoshis are received in exchange.
Le lun. 4 oct. 2021 à 12:28, Luke Dashjr a écrit :
> On Monday 04 October 2021
sadly that's going to increase with Lightning growth and deployment of
other L2s.
Maybe we could dry-up some policy rules in consensus like the dust limit
one :)
Le lun. 4 oct. 2021 à 11:57, Luke Dashjr a écrit :
> On Monday 04 October 2021 15:09:28 Antoine Riard wrote:
> > St
Hi,
I'm writing a report to disclose specification-level vulnerabilities
affecting the Lightning implementations.
The vulnerabilities are expected to be patched in:
* Eclair: v0.6.2+ (CVE-2021-41591)
* LND: v0.13.3+ (CVE-2021-41592)
* LDK: v0.0.102 (not released as production software yet)
The
m/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2=1#slide=id.g85f425098
Thanks to bringing to the surface probabilistic payments, yes that's a
worthy alternative approach for low-value payments to keep in mind.
Le mar. 10 août 2021 à 02:15, David A. Harding a écrit :
> On Mon, Aug 09, 2021 at 09:22:
I'm pretty conservative about increasing the standard dust limit in any
way. This would convert a higher percentage of LN channels capacity into
dust, which is coming with a lowering of funds safety [0]. Of course, we
can adjust the LN security model around dust handling to mitigate the
safety
Hi Ryan,
Thanks for starting this discussion, I agree it's a good time for the
Lightning development community to start this self-introspection on its own
specification process :)
First and foremost, maybe we could take a minute off to celebrate the
success of the BOLT process and the road
nds full with their own
> implementations.
>
> I think we can get the balance right by making progress on this
> (important) discussion whilst also maintaining humility that we don't
> know exact timelines and that getting things merged into Core relies
> on a number of people who
1 - 100 of 150 matches
Mail list logo
