public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	 "lightning-dev\\\\@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>
Cc: security@ariard.me
Subject: [bitcoin-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers
Date: Sun, 22 Oct 2023 03:27:37 +0100	[thread overview]
Message-ID: <CALZpt+HwmacQ9VFu+SfmKms363ZU1xYZe+9o8TsoemTVQLprLg@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2574 bytes --]

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 like massive force-closure beyond available blockspace can absorb
before pre-signed transactions timelocks expiration as mentioned in the
original paper).

I have not yet probed Gleb's mind on this, though we both studied those
cross-layer issues together as early as 2019 / 2020, and I think we have
built an intuitive understanding of the problem-space, with both practical
experience of bitcoin core and rust-lightning codebases and landmark
research in this area [0] [1]. If Gleb isn't too busy with Erlay in core,
I'm sure he'll be enthusiastic to contribute research time at his own pace
(and I might probe a bit of Elichai Turkel time to verify the maths of all
sustainable lightning fixes we might propose and the risks models). All
soft commitments and assuming the interest of the bitcoin community.

One good advantage of long-term sustainable fixes, it should
(optimistically yet to be demonstrated) lower the fee-bumping reserve value
and number of UTXOs lightning users (and maybe bandwidth) have to lock
continuously to use this worldwide 24 / 7 payment system.

Reopened the issue on coordinated security issues handling in the LN
ecosystem:
https://github.com/lightning/bolts/pull/772

While I'll stay focused on solving the above problems at the base-layer
where they're best solved, at least I'll stay around for a few months
making transitions with the younger generation of LN devs.

For transparency, I don't have any strong solution design yet at all,
neither code, conceptual draft or paper ready, and game-theory and nodes
network processing resources changes will have to be weighted very
carefully, all under the bitcoin open and responsible process we currently
have. Overall, this will take reasonable time (e.g package relay design
discussions have been started in 2018 and we're only now at the hard
implementation and review phase) to carry on forward.

Looking forward to hearing thoughts of the Bitcoin and Lightning
development protocols community.

[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002569.html
[1] https://arxiv.org/pdf/2006.01418.pdf

"They who face calamity without wincing, and who offer the most energetic
resistance, these, be they States or individuals, are the truest heroes". -
Thucydides.

[-- Attachment #2: Type: text/html, Size: 3097 bytes --]

             reply	other threads:[~2023-10-22  2:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-22  2:27 Antoine Riard [this message]
2023-11-15 18:14 ` [bitcoin-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers Antoine Riard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALZpt+HwmacQ9VFu+SfmKms363ZU1xYZe+9o8TsoemTVQLprLg@mail.gmail.com \
    --to=antoine.riard@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    --cc=security@ariard.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox