Hi all,
Eltoo has been criticized to lower the cost for a malicious party to
test your monitoring of the chain. If we're able to reintroduce some
form of punishment without breaking transaction symmetry that would be
great.
Transaction symmetry implies that we can't deduce from observing
txid
Hi ZmnSCPxj,
Awesome resume, it's better lay-out than I did myself !!
> Thus, I would like to thank you for your tolerance and continued
attention.
Personally, it's a pleasure to read your weird but always thoughtful
proposals in other threads :)
"We have identified two requirements:
1. We
Hi ZmnSCPxj,
> Just a minor correction here: your own commitment transactions are not
> being signed until we want to release them. Therefore having access to
> your DB doesn't give an attacker the ability to frame the user with an
> old version, since that'd still require access to the keys to
Time-Dilation Attacks on Offchain Protocols
===
Lightning works on reversing the double-spend problem to a private
state between parties instead of being a public issue verified by every
network peer. The security model is based on revocation of previous
states and
54:19 CET, "David A. Harding"
> wrote:
>>
>> On Mon, Dec 09, 2019 at 01:04:07PM -0500, Antoine Riard wrote:
>>
>>> Time-Dilation Attacks on Offchain Protocols
>>> --
>>>
>>
>> What is the advantag
do a fallback is
> nontrivial, especially if you are concerned with user privacy.
>
> Matt
>
> On 12/16/19 9:10 AM, David A. Harding wrote:
> > On Mon, Dec 16, 2019 at 02:17:31AM -0500, Antoine Riard wrote:
> >> If well executed, attacks described stay stealth un
Hi,
Design reason of trampoline routing was to avoid lite nodes having
to store the whole network graph and compute long-hop route. Trick
lays in getting away from source-base routing, which has the nice
property to hide hop position along the payment route (if we forget
payment hash
Hi Bastien,
The use case you're describing strikes me as similar to a slashing protocol
for a LN node and a watchtower, i.e punishing
a lazy watchtower for not broadcasting a penalty tx on remote revoked
state. In both case you want "if A don't do X
unlock some funds for B".
Here a rough
Hey thanks for this proposal!
2 high-level questions:
What about multi-party tx construction ? By multi-party, let's define
Alice initiate a tx construction to Bob and then Bob announce a
construction to Caroll and "bridge" all inputs/outputs
additions/substractions
in both directions. I think
Hi Max,
Sorry by transaction format I didn't mean a binary transaction format,
but format like we use in BOLT3 :
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md
My concern is, e.g LN implementations setting nLocktime to 0x,
Coinjoin wallets always
ei)
>
>
> Antoine
>
>
> ---- Original Message
> On Jan 30, 2020, 01:21, Antoine Riard < antoine.ri...@gmail.com> wrote:
>
>
> Hey thanks for this proposal!
>
> 2 high-level questions:
>
> What about multi-party tx constructi
Darosior ( i'll stick with my pseudo, first names definitely don't have
> enough entropy :-) )
> Original Message ----
> On Jan 30, 2020, 19:09, Antoine Riard < antoine.ri...@gmail.com> wrote:
>
>
> Hey Darosior,
>
> You don't need a strict synchronization bet
Hey Zeeman,
tl;dr A LN node paired with an external signer can be distrusted and LN
funds be safe in any case
if signer is connected to a N-set of watchtowers and at least one of them
is non-compromised.
Thanks for this interesting post, I was thinking about LN hardware wallets
support for a
Personally, I would have wait a bit before to go public on this, like
letting some implementations
increasing their CLTV deltas, but anyway, it's here now.
Mempool-pinning attacks were already discussed on this list [0], but what
we found is you
can _reverse_ the scenario, where it's not the
dev wrote:
> > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev <
> > bitcoin-...@lists.linuxfoundation.org> wrote:
> >
> >> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> >>> Trust-minimization of Bitcoin security
> * At the same time, it retains your-keys-your-coins noncustodiality,
because every update of a Lightning channel requires your keys to sign off
on it.
Yes I agree, I can foresee an easier step where managing low-value channel
and get your familiar with smooth key management maybe a first step
Lightning protocol supports a floating dust output selection at channel
creation, where each party declares a dust parameter applying to its local
transactions. The current spec doesn't enforce or recommend any bound on
this value, beyond the requirement of being lower that
out miners.
>
> Keagan
>
> On Wed, May 6, 2020 at 3:06 AM Antoine Riard
> wrote:
>
>> I do see the consensus capture argument by miners but in reality isn't
>> this attack scenario have a lot of assumptions on topology an deployment ?
>>
>> For such attack
> The choice between whether we offer them a light client technology that
is better or worse for privacy and scalability.
And offer them a solution which would scale in the long-term.
Again it's not an argumentation against BIP 157 protocol in itself, the
problem I'm interested in is how
ess to a single header/filter, a range of them in the past, or N headers
> past the known chain tip, etc, etc.
>
> -- Laolu
>
> [1]: https://lsat.tech/
> [2]: https://lightning.engineering/posts/2020-03-30-lsat/
>
>
> On Tue, May 5, 2020 at 3:17 AM Antoine Riard
> wrote:
>
>
foster node adoption as much as we can.
Le mar. 5 mai 2020 à 09:01, Luke Dashjr a écrit :
> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
> > Trust-minimization of Bitcoin security model has always relied first and
> > above on running a full-node. This curre
Hi,
(cross-posting as it's really both layers concerned)
Ongoing advancement of BIP 157 implementation in Core maybe the opportunity
to reflect on the future of light client protocols and use this knowledge
to make better-informed decisions about what kind of infrastructure is
needed to support
Africans and
> Europeans serving the Asians in kind. By plugging in our phones and going
> to sleep we could blanket the whole world in (somewhat) full nodes!
>
> Cheers,
> Igor
>
> [1] https://icota.github.io/
>
> On Tue, 5 May 2020 at 12:18, Antoine Riard
> wrot
Hi Christopher,
Thanks for Blockchain Commons and Learning Bitcoin from the Command Line!
> If there are people interested in coordinating some proposals on how to
defining different sets of wallet functionality, Blockchain Commons would
be interested in hosting that collaboration. This could
Hi,
In this post, I would like to expose a potential vulnerability introduced
by the recent anchor output spec update related to the new usage of
SIGHASH_SINGLE for HTLC transactions. This new malleability combined with
the currently deployed mechanism of `update_fee` is likely harmful for
funds
ll now also look into setting clamps on the
> receiver end to just not accept unreasonable values for the fee rate of a
> commitment, as this ends up eating into the true HTLC values for both
> sides.
>
> -- Laolu
>
>
> On Thu, Sep 10, 2020 at 9:28 AM Antoine Riard
> w
h can potentially cascade.
> >
> > In lnd today, anchors is still behind a build flag, but we plan to enable
> > it by default for our upcoming 0.12 release. The blockers on our end
> were to
> > add support for towers, and add basic deadline aware bumping, both of
>
> There is no need to stop the channel's operations while you're updating
these parameters, since
they can be updated unilaterally anyway
I think it's just how you defne channel's operations, either emptying out
all pending HTLCs or more a `update_fee` alike semantic. You're right that
the latter
Hi Zeeman,
> * It requires a lot more communication rounds and (symmetric, at least)
cryptographic operations.
At first sight, it sounds similar to HORNET/rendez-vous, at least in the
goal of achieving bidirectional communications.
* Intermediate nodes can guess the distance from the source by
Hi Joost,
Thanks for your proposal, please find my following opinion which is
deliberately on a high-level as IMO defining better threats model and
agreeing on expected network dynamics resulting from any solution
trade-offs sounds required before to work on any solution.
> We've looked at all
Hello Bastien,
As a first note , I was thinking dynamic policy adjustment would be covered
by the dynamic commitment mechanism proposed by Laolu as it presents the
same trade-offs, you need to stop channel HTLC processing before upgrading,
otherwise it might falsify your whole in-flight HTLC
Hello Bastien,
I'm all in for a model where channel transactions are pre-signed with a
reasonable minimal relay fee and the adjustment is done by the closer. The
channel initiator shouldn't have to pay for channel-closing as it's somehow
a liquidity allocation decision ("My balance could be
Hi Zeeman,
> i.e. I send my high-fee RBF-enabled channel funding to you, at the same
time I send a conflicting low-fee RBF-disabled transaction (that pays the
entire channel amount to myself) to all the miners I can find.
Mapping miners mempools will be a cost in spying infrastructure and thus
Hi Roei,
You might have a mechanism to lower trust in zero-conf channel opener.
Actually the local party can be in charge of broadcasting the funding
transaction, thus ensuring it's well-propagated across network mempools and
then start to accept incoming payment on the zero-conf channel. Per BIP
Hi Laolu,
I think that's a must before we introduce a bunch of new features and the
number of channels explodes. The de-synchronized side could be underscored
more as any scheduled, automatic, massive upgrade for security forcing
chain writes can be exploited to launch mempool-congestion
(tl;dr Ideally network mempools should be an efficient marketplace leading
to discovery of best-feerate blockspace demand by miners. It's not due to
current anti-DoS rules assumptions and it's quite harmful for shared-utxo
protocols like LN)
Hello all,
Lightning security model relies on the
Hi Rene,
Thanks for disclosing this vulnerability,
I think this blackmail scenario holds but sadly there is a lower scenario.
Both "Flood & Loot" and your blackmail attack rely on `update_fee`
mechanism and unbounded commitment transaction size inflation. Though the
first to provoke block
# Problem
In case of a relayed HTLC hash-and-amount collision with an expected
payment HTLC on the same channel, LND was releasing the preimage for the
later while claiming onchain the former. A malicious peer could have
deliberately intercepted a HTLC intended for the victim node, probe the
# Problem
A lightning node must verify that its channel transactions are not only
consensus-valid but also tx-relay standard. The counterparty signatures are
part of the local txn (commitment/HTLC) as provided in the
`commitment_signed`. Verifying consensus-validity of these signatures but
not
# Problem
A lightning node must verify that its channel transactions are not only
consensus-valid but also tx-relay standard. The counterparty signatures are
part of the local txn (commitment/HTLC) as provided in the
`commitment_signed`. Verifying consensus-validity of these signatures but
not
Hi,
A short reminder about the 1st transaction relay workshop happening
tomorrow on #l2-onchain-support Libera chat (!), Tuesday 15th June, from
19:00 UTC to 20:30 UTC
Scheduled topics are:
* "Guidelines about L2 protocols onchain security design"
* "Coordinated cross-layers security
> That's a question I hope we'll gather feedback during next Thursday's
transaction relay workshops.
As someone kindly pointed out to me, workshop is happening Tuesday, June
22th. Not Thursday, mistake of mine :/
Le ven. 18 juin 2021 à 18:11, Antoine Riard a
écrit :
> Hi,
>
>
Hi,
I was super glad to see the recent survey on potential softforks for the
near-future of Bitcoin! I didn't have time to answer this one but will do
so for the future. I wanna to salute the grassroots involvement in bitcoin
protocol development, that's cool to see :)
Though softforks are what
ub.com/bitcoin/bitcoin/issues/14895
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002569.html
Le sam. 19 juin 2021 à 09:38, David A. Harding a écrit :
> On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote:
> > 2) Solving the Pre-Signed Feerate problem
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
Hi,
It's a big chunk, so if you don't have time browse parts 1 and 2 and share
your 2 sats on the deployment timeline :p
This post recalls some unsolved safety holes about Lightning, how
package-relay or SIGHASH_ANYPREVOUT can solve the first one, how a mempool
hardening can solve the second
Hi,
In this post I would like to highlight some DoS attacks against multi-party
Bitcoin protocols during their funding phases. Recent discussions around
DLC funding flow [0] and dual-funding of LN channel [1] remind me that some
timevalue DoS/fee inflation issues are common to any multi-party
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
Hi,
During the lastest years, tx-relay and mempool acceptances rules of the
base layer have been sources of major security and operational concerns for
Lightning and other Bitcoin second-layers [0]. I think those areas require
significant improvements to ease design and deployment of higher
0 block lock
> on spending a sponsoring tx which would hopefully make less controversial,
> this would be a great place to discuss those tradeoffs.
>
> On Fri, Apr 23, 2021, 8:17 AM Antoine Riard
> wrote:
>
>> Hi,
>>
>> During the lastest years, tx-relay and mempool
Hi Joost,
Thanks for working on this and keeping raising awareness about channel
jamming.
> In this post I'd like to present a variation of bidirectional upfront
payments that uses a time-proportional hold fee rate to address the
limitation above. I also tried to come up with a system that aims
a first attempt at projecting this idea onto the existing spec:
> https://github.com/lightningnetwork/lightning-rfc/pull/843. This may also
> clarify some of the questions that haven't been answered yet.
>
> Joost
>
> On Fri, Feb 12, 2021 at 2:29 PM Antoine Riard
> wro
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
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:
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
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
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
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
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
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
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 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
(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
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
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
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
&
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
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
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 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,
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 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
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
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
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
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
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,
>>
>>
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
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
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
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:/
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
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
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
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
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
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
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 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
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
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:
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
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
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 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
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 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
1 - 100 of 150 matches
Mail list logo
