Good morning Antoine et al.,
Let me try to rephrase the core of the attack.
There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, `==`
are channels):
A = B = C
`A` routes `A->B->C`.
The timelocks, for example, could be:
A->B timeelock = 144
B->C timelock
> ## Deployed LN mitigations
>
> Aggressive rebroadcasting: As the replacement cycling attacker benefits from
> the HTLC-timeout being usually broadcast by lightning nodes only once every
> block, or less the replacement cycling malicious transactions paid only equal
> the sum of the absolute fe
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. `S
Good morning Bastien,
I have not gotten around to posting it yet, but I have a write-up in my
computer with the title:
> Batched Splicing Considered Risky
The core of the risk is that if:
* I have no funds right now in a channel (e.g. the LSP allowed me to have 0
reserve, or this is a newly-s
> I do not know if existing splice implementations actually perform such a
check.
Unless all splice implementations do this, then any kind of batched
splicing is risky.
As long as the implementation decides to splice again at some point when a
prior
splice isn't confirming, it will self-resolve on
Good morning Greg,
> > I do not know if existing splice implementations actually perform such a
> > check.
> Unless all splice implementations do this, then any kind of batched splicing
> is risky.
> As long as the implementation decides to splice again at some point when a
> prior
> splice
While I haven't looked at the BitVM in detail, I would like to mention that
Simplicity's core language (excluding introspection primitives) has the
same expressivity as Boolean circuits.
A few years ago I did some experiments to compile Simplicity expressions to
a system of polynomial constraints
Hi Ziggie,
> thanks for this detailed explanation. This class of pinning attacks sound
not too unlikely especially if the attacker targets channels with high
capacity and very loose channel policies (allowing the full htlc
> amount to be the channel capacity). Could you add more details about the
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 HTLC
> We have conducted one so far, multiple scenarios to look at.
_*none*_ so far. typo of mine - apologize english is not my native language.
We discussed conducting experiments pre-disclosure in an e-mail of the 11th
August 2023.
"If someone is down to setup a "black box" Lightning infra on maine
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 doe
There appears to be some confusion about this issue and the mitigations. To be clear, the deployed
mitigations are not expected to fix this issue, its arguable if they provide anything more than a PR
statement.
There are two discussed mitigations here - mempool scanning and transaction
re-sign
12 matches
Mail list logo
