path: root/d9/8692398d3858c104cbee92637b05fecabc89f8

Delivery-date: Tue, 27 Aug 2024 14:13:20 -0700
Received: from mail-yb1-f187.google.com ([209.85.219.187])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBZ4CXG3AMGQEE3LW76A@googlegroups.com>)
	id 1sj3V9-0005bC-O3
	for bitcoindev@gnusha.org; Tue, 27 Aug 2024 14:13:20 -0700
Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-dfd377669d6sf1650651276.1
        for <bitcoindev@gnusha.org>; Tue, 27 Aug 2024 14:13:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1724793193; x=1725397993; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=G0gt5s6Fhajviyp7zAc+EMIcC15kvK1Zop8nXWa9sJ4=;
        b=WFjPOPVLyXhezYtXGTaswFDLTmR7ONry1KTbX0HrpCFIE3UFhBY16iHdquoymjLn3T
         +FJhpqoeJkYQW0bhcq9p5/zheFQ16pl7ySyKi5jixlVk5Oc3onMiYTIdghSOXK053hfs
         BJr4dgaxEsyt3uetb5/NNkl0PIavBw+ArOEr0AHnuI5MATG+PQRgu6bBCN7aju6Bin79
         /AKowsJkHIJ2vzqH9JitbwsLKeLuBuqOeXWO0LtmzOx1qZcX3d4gOflU/Eg0OBQptmS/
         aL/DW8D9IUYG2Jc7m0gpjsUVhCSJ6+VkRHSUlp2phvRvDeqCBAGuFe8OYtERJXcXyAts
         qchQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1724793193; x=1725397993; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=G0gt5s6Fhajviyp7zAc+EMIcC15kvK1Zop8nXWa9sJ4=;
        b=lLINvWsB5wIDiGrGkFRmhV1XZDC3J5Po83dNeSMRqm6+8UwM4t3gTqjxiOqgFTu1UU
         7tTBQXdwyj5T3otQPHvz8gRZp8rU1WxtKyH8kyyd16jeE2HeJ2tzwyP60hRWHCpbZo0l
         lJOM86+pn9NhGnlPcB20dPFHka1f+c/eLQ0d4VQhgMlWertBq9KnXQ+bg9tb0I2/54UT
         p7iKwH1IJ5IZzWwT8Vlvyf0B21Qt6sXQ8DncgHICYZWsLqWs3b7nr1LRahGOHK+toNw5
         TITI3vSBjJvd/+pG1oV2bzspVZVy/NWnDs0wxO5y+xkm1EOZNIQW7qFktNXTEEDrnrJy
         sEdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1724793193; x=1725397993;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=G0gt5s6Fhajviyp7zAc+EMIcC15kvK1Zop8nXWa9sJ4=;
        b=u/nHQqxmWS6MEQ12UeWHZgaW8sLLPznf61H5WNz50d2nZdBigEY9D9pKdrEtjytVPW
         m0C37Jvbw3zQvFe+uvYnHLSRfVHcx3LX0tLcMW4hQ5WFupJndwCqqMjzD01ekjGlcTNb
         +ozZzWNGNeyK1WeNxQQkdcVqKTEQGWLhs1NVlc8SBHeK/4ZZuEb/VlOsE2QbZY1c1l7M
         mSs4YcK1RChib2FMWWlBHaT054Ngr/v/hmJkD01bly2UG9CujQKmRkgOTrm9kQeHC0+X
         iV1KPSsQbeYXKl+bP6ixq6BGofR0UlA0cBV3kkbAmeYlzsoo2jOpyROxArnMecLeXS2D
         uSvg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVQpZ2V3Xd/eVyC+QOhCCkL2JkQ/wNrBZKo/rUqWpOjfNNCF7DMWUA19bL/sc+pQxyKq5ZeFVuWx1Vd@gnusha.org
X-Gm-Message-State: AOJu0YzReFFzpY5DOYJhsKvYw9YbTjdJPNfBQhkk5BtaVBXewUVDfr0e
	u1NZQIktmEbiXBn+2UQMtk32gGgRiYpVYhkPA/MnNzU0Lw7j/nKL
X-Google-Smtp-Source: AGHT+IFGC8LCYSzpVvTZqd5mI5pR9Q4eFneyo1nHjg1t7ioopqU0MXcNATr3mOdEye1ZhFR5J9hdjg==
X-Received: by 2002:a05:6902:11c9:b0:dfd:b41f:7f5c with SMTP id 3f1490d57ef6-e17a86797a2mr7114624276.4.1724793192894;
        Tue, 27 Aug 2024 14:13:12 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:72e:b0:e14:d13e:ee39 with SMTP id
 3f1490d57ef6-e178bd483f5ls723296276.2.-pod-prod-02-us; Tue, 27 Aug 2024
 14:13:11 -0700 (PDT)
X-Received: by 2002:a05:690c:6482:b0:6be:5e3b:d25f with SMTP id 00721157ae682-6c6286b9b67mr178424397b3.29.1724793190916;
        Tue, 27 Aug 2024 14:13:10 -0700 (PDT)
Received: by 2002:a81:ec0c:0:b0:64a:6fb4:b878 with SMTP id 00721157ae682-6d006d99818ms7b3;
        Tue, 27 Aug 2024 14:10:17 -0700 (PDT)
X-Received: by 2002:a05:690c:1e:b0:6c9:9341:1f9a with SMTP id 00721157ae682-6c993412c95mr110604187b3.10.1724793015869;
        Tue, 27 Aug 2024 14:10:15 -0700 (PDT)
Date: Tue, 27 Aug 2024 14:10:15 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <a647a2e2-2742-4b0e-ae84-6f84b018136fn@googlegroups.com>
Subject: [bitcoindev] Demonstrating Pinning Attacks under Real-World Conditions
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_78084_259696461.1724793015692"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_78084_259696461.1724793015692
Content-Type: multipart/alternative; 
	boundary="----=_Part_78085_2002175145.1724793015692"

------=_Part_78085_2002175145.1724793015692
Content-Type: text/plain; charset="UTF-8"

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.

------=_Part_78085_2002175145.1724793015692
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi list,<br /><br />I'm following-up on Dave Harding''s proposition in anot=
her recent email thread.<br /><br />&gt; How would that work? AFAIK, there'=
s no LN software using TRUC, very few <br />&gt; relay nodes are using it (=
since it isn't yet enabled by default in a <br />&gt; release version), and=
 no miners are using it (again, since it hasn't <br />&gt; been released). =
I'm willing to put money at stake to settle a <br />&gt; disagreement that =
can't be settled with words, but I want to at least <br />&gt; learn someth=
ing from the process. <br /><br />I think it would benefit greatly the bitc=
oin ecosystem to have in place few<br />lightning nodes running on mainnet,=
 against which folks can freely exercise <br />sophisticated cross-layers a=
ttacks (e.g pinning) to demonstrate their feasibility<br />and severity, in=
 a plain fashion.<br /><br />Indeed, this is one thing to execute an attack=
 on a private regtest or even<br />testnet, another on mainnet in real-worl=
d conditions where the results can be<br />evaluated and discussed by a wid=
e audience. I already call to put in place such <br />attack demonstration =
experiences in the past (cf. in the context of the transaction<br />relay w=
orkshop in 2021 [0]) and it would be more akin to the research standards<br=
 />at major sec confs demanding for artifacts.<br /><br />So if we have mor=
e candidates, beyond Dave, who wish to put in place "free-to-pown"<br />lig=
htning nodes, the basic setup could be the following for useful demo attack=
s results:<br />- a full-node (e.g core or btcd)<br />- a ligtning node (e.=
g core-lightning / ldk / lnd)<br />- running default mainnet setting for bo=
th softwares<br /><br />What else ?<br /><br />It is more interesting to ru=
n with default mainnet settings, as testnet / regtest<br />have usually myr=
iads of specific behaviors and have all the real mempools congestion<br />c=
ycles to deal with. As someone wishing to do attack demo, I'm fine pouring =
the satoshis<br />funds to open new channels, you only need to be above the=
 dust threshold to exercise<br />interesting attacks.<br /><br />A cynical =
observer of bitcoin and lightning protocol development (of which, of course=
<br />I'm not !), could say that given the level of technical complexity of=
 a full-node<br />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 =C2=A0belief 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 economic=
s units) [1].<br /><br />From the viewpoint of a security researcher wishin=
g to demonstrate the feasibility<br />and severity of some cross-layers att=
acks in bitcoin, having running public nodes would<br />be very useful. The=
re is also the option to do that on private infra and come back with<br />a=
 trace on mainnet, though it would lose its public verifiability aspect.<br=
 /><br />My utmost pleasure to demonstrate some pinning attacks on nodes un=
der real-world conditions.<br /><br />Cheers,<br />Antoine<br />ots hash: 6=
3f58d2557beef5eb1b04f530f91d3febd682ae078933790fcdc1ac94356cf40<br /><br />=
[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018925=
.html<br />[1] And on that regard, it's often the ones who are spending the=
ir time on social medias<br />and numerous podcasts whining about the purit=
y of their intention or always recalling their FOSS veterans credentials as=
 some mark of authority who are the more suspicious to falter about some se=
nse of accountability towards end-users...It can be good to re-read Nietzsc=
he.<br />

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/a647a2e2-2742-4b0e-ae84-6f84b018136fn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/a647a2e2-2742-4b0e-ae84-6f84b018136fn%40googlegroups.com</a>.=
<br />

------=_Part_78085_2002175145.1724793015692--

------=_Part_78084_259696461.1724793015692--