Hi list,
As I received a lot of feedback on the full disclosure of the 16th week of
October and the following posts, some accurate, I'm taking time to address
a few of them.
I think one of the most recurring feedback is the fact that the replacement
cycling issue laid out in the initial full
On Sat, Oct 21, 2023 at 09:05:35PM +0100, Antoine Riard via bitcoin-dev wrote:
> In the meanwhile, lightning experts have already deployed mitigations which
> are hardening the lightning ecosystem significantly in face of simple or
> medium attacks. More advanced attacks can only be mounted if you
On 2023-10-21 18:49, Nadav Ivgi via bitcoin-dev wrote:
Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode
that requires _all_ inputs to have a matching nSequence, and using `1
OP_CSV_ALLINPUTS` in the HTLC preimage branch?
This would prevent using unconfirmed outputs in the
Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode that
requires *all* inputs to have a matching nSequence, and using `1
OP_CSV_ALLINPUTS` in the HTLC preimage branch?
This would prevent using unconfirmed outputs in the HTLC-preimage-spending
transaction entirely, which IIUC
Hi,
As I've been shown offline Twitter posts misrepresenting my previous mail,
I think it's good to correct them. The security flaws are not "intentional
backdoor" or whatever misrepresentation that would question the competence
and know-how of the Bitcoin and Lightning development community.
I found the original explanation a bit confusing. As I understand it,
the attack starts by double-spending the timeout HTLC transaction of
the victim with a pre-image revealing HTLC transaction. This itself
is not an attack: the victim can then use the pre-image to receive its
incoming HTLC
On Tue, Oct 17, 2023 at 02:11:20AM +0100, Antoine Riard wrote:
> > I think if you want people to understand this exploit, you need to
> explain in more detail how we have a situation where two different parties
> can spend the same HTLC txout, without the first party having the right to
> spend it
Hi,
After writing the mail reply on the economics of sequential malicious
replacement of honest HTLC-timeout, I did write one more test to verify the
behavior on core mempool, and it works as expected.
https://github.com/ariard/bitcoin/commit/30f5d5b270e4ff195e8dcb9ef6b7ddcc5f6a1bf2
Responsible
> I think if you want people to understand this exploit, you need to
explain in more detail how we have a situation where two different parties
can spend the same HTLC txout, without the first party having the right to
spend it via their knowledge of the HTLC-preimage.
If I'm correctly
Hi Antoine,
Thanks for this great write up, and also your diligence in reporting this
issue to the various implementations, and game planning with us re
mitigations and attack scenarios.
One small clarification: all of lnd's relevant mitigations were in place by
lnd v0.16.1-beta [1], which was
On Mon, Oct 16, 2023 at 7:21 PM Peter Todd via bitcoin-dev
wrote:
> I think if you want people to understand this exploit, you need to explain in
> more detail how we have a situation where two different parties can spend the
> same HTLC txout, without the first party having the right to spend
On October 16, 2023 6:57:36 PM GMT+02:00, Antoine Riard via bitcoin-dev
wrote:
>(cross-posting mempool issues identified are exposing lightning chan to
>loss of funds risks, other multi-party bitcoin apps might be affected)
>
>As the HTLC-preimage spends an unconfirmed input that was already
(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
13 matches
Mail list logo
