From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Demonstrating Pinning Attacks under Real-World Conditions
Date: Tue, 27 Aug 2024 14:10:15 -0700 (PDT) [thread overview]
Message-ID: <a647a2e2-2742-4b0e-ae84-6f84b018136fn@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3803 bytes --]
Hi list,
I'm following-up on Dave Harding''s proposition in another recent email
thread.
> How would that work? AFAIK, there's no LN software using TRUC, very few
> relay nodes are using it (since it isn't yet enabled by default in a
> release version), and no miners are using it (again, since it hasn't
> been released). I'm willing to put money at stake to settle a
> disagreement that can't be settled with words, but I want to at least
> learn something from the process.
I think it would benefit greatly the bitcoin ecosystem to have in place few
lightning nodes running on mainnet, against which folks can freely exercise
sophisticated cross-layers attacks (e.g pinning) to demonstrate their
feasibility
and severity, in a plain fashion.
Indeed, this is one thing to execute an attack on a private regtest or even
testnet, another on mainnet in real-world conditions where the results can
be
evaluated and discussed by a wide audience. I already call to put in place
such
attack demonstration experiences in the past (cf. in the context of the
transaction
relay workshop in 2021 [0]) and it would be more akin to the research
standards
at major sec confs demanding for artifacts.
So if we have more candidates, beyond Dave, who wish to put in place
"free-to-pown"
lightning nodes, the basic setup could be the following for useful demo
attacks results:
- a full-node (e.g core or btcd)
- a ligtning node (e.g core-lightning / ldk / lnd)
- running default mainnet setting for both softwares
What else ?
It is more interesting to run with default mainnet settings, as testnet /
regtest
have usually myriads of specific behaviors and have all the real mempools
congestion
cycles to deal with. As someone wishing to do attack demo, I'm fine pouring
the satoshis
funds to open new channels, you only need to be above the dust threshold to
exercise
interesting attacks.
A cynical observer of bitcoin and lightning protocol development (of which,
of course
I'm not !), could say that given the level of technical complexity of a
full-node
software and a lightning implementation and the hardness to evaluate
cross-layer attacks like pinning, some lightning domain experts and
maintainers are deliberately abusing the belief of lightning end-users
about the protocol robustness and as such misleading end-users about the
safety of their moneys (and LSPs about the viability of their economics
units) [1].
From the viewpoint of a security researcher wishing to demonstrate the
feasibility
and severity of some cross-layers attacks in bitcoin, having running public
nodes would
be very useful. There is also the option to do that on private infra and
come back with
a trace on mainnet, though it would lose its public verifiability aspect.
My utmost pleasure to demonstrate some pinning attacks on nodes under
real-world conditions.
Cheers,
Antoine
ots hash: 63f58d2557beef5eb1b04f530f91d3febd682ae078933790fcdc1ac94356cf40
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018925.html
[1] And on that regard, it's often the ones who are spending their time on
social medias
and numerous podcasts whining about the purity of their intention or always
recalling their FOSS veterans credentials as some mark of authority who are
the more suspicious to falter about some sense of accountability towards
end-users...It can be good to re-read Nietzsche.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/a647a2e2-2742-4b0e-ae84-6f84b018136fn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4333 bytes --]
next reply other threads:[~2024-08-27 21:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 21:10 Antoine Riard [this message]
2024-09-03 12:58 ` Peter Todd
2024-09-03 20:12 ` 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=a647a2e2-2742-4b0e-ae84-6f84b018136fn@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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