path: root/2a/86682deb5763118ee25b59010243691eed0fa1

Return-Path: <alicexbt@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8F05BC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 26 Jun 2022 16:40:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 6203960B5B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 26 Jun 2022 16:40:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6203960B5B
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=qc6y8Qg2
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7CqxjGXwzWQx
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 26 Jun 2022 16:40:37 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 268A560B10
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 268A560B10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 26 Jun 2022 16:40:36 +0000 (UTC)
Date: Sun, 26 Jun 2022 16:40:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1656261632; x=1656520832;
 bh=1YzYVzk5b4c8dGNZOlv9R+444lTHLK8MJi2ijGOAWec=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
 Feedback-ID:Message-ID;
 b=qc6y8Qg23TpQI1LfP5ifXjzinb/StkjsftxbYvYf2tPW/kFGr4fkELqfTsTA2BTq3
 Oke3QmSKe6pteSwbYZPIqYkpODsXh1+YjuCqcLTF4LdjHRC8+/5twC4TJP6jyFo+p4
 Yz3/e/6HfsYnX73v5z6ysfY+c+Ed7z/pPllNrDqOjf+ThqoY8uKW8TOn5NjTXRndjv
 DF6LAMayeUiHnSAzFcA/eA4gtQcWCczemDeqLUy9Z5z1kc3re8ew2iGhK/OT3yuFRu
 siaR+2OnbvuLsRDYKGHDoQlI8Hvz5TSl2fmfpPeQ13y4L//PyjSDfIGVG+Ia2s1ZYP
 u+BquN+p/swPg==
To: Antoine Riard <antoine.riard@gmail.com>
From: alicexbt <alicexbt@protonmail.com>
Reply-To: alicexbt <alicexbt@protonmail.com>
Message-ID: <Pb8H4PbeS-RaNOKfekOPdY8gQo4_Syd3HoTK26AO872f7tCKyGnty56KtcvmvrXFOJdC7nQgNHoQ37M4MNXQ6vqQ9du6BFbvGLbY3BdYVpY=@protonmail.com>
In-Reply-To: <CALZpt+HXB=xh3qtxJFM7yUzRu1uj-pPtLQmT=5QV0dNfVuTpfQ@mail.gmail.com>
References: <CALZpt+GOh-7weEypT9JrzcwthZJqHOfj7sf9FMuqi5_FZv0g7w@mail.gmail.com>
 <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
 <CALZpt+FJ-R9yCoMLP=Vcxk1U7n=-LKHUGctFZj0K-vTMsz==ew@mail.gmail.com>
 <RJEFmrnjbzKQCBr4L7ebwBLzg7QHGXlaE19zj6jfkxL6xjfodgbfssZBQSYxm783Y4X5awuhL9Gj8IaBc4npE2oh3d1xoudKTrSsJ-dk0VQ=@protonmail.com>
 <CALZpt+HXB=xh3qtxJFM7yUzRu1uj-pPtLQmT=5QV0dNfVuTpfQ@mail.gmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 26 Jun 2022 23:27:14 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s
	security
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jun 2022 16:40:40 -0000

Hi Antoine,

Thanks for sharing the DoS attack example with alternatives.

> - Caroll broadcasts a double-spend of her own input C, the double-spend i=
s attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
> - Alice broadcasts the multi-party transaction, it is rejected by the net=
work mempools because Alice double-spend is already present

I think this affects almost all types of coinjoin transaction including coo=
rdinator based implementations. I tried a few things and have already repor=
ted details for an example DoS attack to one of the team but there is no re=
sponse yet.

It was fun playing with RBF, DoS and Coinjoin. Affected projects should sha=
re their opinion about full-rbf as it seems it might improve things.

Example:

In Wasabi an attacker can broadcast a transaction spending input used in co=
injoin after sending signature in the round. This would result in a coinjoi=
n tx which never gets relayed: https://nitter.net/1440000bytes/status/15407=
27534093905920

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, June 21st, 2022 at 11:43 PM, Antoine Riard <antoine.riard@gmail=
.com> wrote:


> HI alicexbt,
>
> > Lets consider there are 2 users with name Bob (normal LN user) and Caro=
l (attacker running LN node) which I will use in this email for examples. I=
n this case Bob and Carol can manage security of their OS and it is not aff=
ected by others using vulnerable systems or OS.
>
> Yes, I believe my argument was the set of components making the security =
of your LN node is far beyond Bitcoin softwares. Of course, you might revie=
w by yourself the millions lines of code entering in the trusted computing =
base (OS, bootloader, BIOS, device firmwares, essential utilities, ...) on =
which your cryptocurrency software stack lays out, and as such exercise an =
extended span of control on your personal computation. Though, while I hope=
 we'll have more LN node operators doing so, I'm not sure it's realistic to=
 expect it will be the behavior standard among them..
>
> > The odds are low as you said, this can be managed by Bob and Carol beca=
use they can use a better ISP. Others using ISP with some issues may not af=
fect their LN usage.
>
> Sure, though as I would like to underscore being dependent on a Bitcoin n=
ode policy and being dependent on a ISP internet traffic routing policy cou=
ld be analyzed as logically equivalent, all things are equal. That said, if=
 your personal risk aversion is too high for the Lightning security model, =
once it's well-understood there is a strong reliance on a censorship-resist=
ant tx-relay network back to economically-rational miners, you're free to n=
ot use it and satisfy yourself with the Bitcoin base layer.
>
> > Bob might use full-rbf as its suggested by LN developers for secure LN =
usage and better for miners. Carol could use a different RBF policy for som=
e nodes and mining. In this case Bob may get affected at some point because=
 of Carol's choice to use a different RBF policy which was not true above.
>
> Indeed, your secure LN usage is going to be dependent of the number of p2=
p network nodes running an economically-rational policy like full-rbf. That=
 said, I think it's reasonable to assume that the players of the Bitcoin ga=
me are economically-rational, and as such incentived to pick up a policy su=
ch as full-rbf. I know the term "economically-rational" is poorly defined h=
ere, and I think it could be interesting for any academic with an economic =
background to study the incentives of Bitcoin actors.
>
> > Allowing users to create different mempool policies is great. My though=
t process is to code for happy path, where X policy is expected for replace=
ment and edge cases where Y policy or no policy would be used. Users can tr=
y out different policies and even act as attackers. This is also true for o=
ther things in mempool, 'spkreuse=3Dconflict' prevents address reuse in the=
 mempool when using knots. If I assume that address reuse is always relayed=
, this could become a problem if some users and miners adopt this setting i=
n their mempool.
>
> Agree, I'm all in for people to experiment with mempool policies. Though =
at the end it's a software engineering resource question. If users are inte=
rested in more features, they're always free to implement themselves. Reall=
y, the binary distinction developers-vs-users doesn't make sense and if we =
would like Bitcoin to be successful in the long-term, we should promote hig=
h degree of software literacy among bitcoiners.
>
> > This makes sense and I would be interested to follow two things once fu=
ll-rbf is available in a bitcoin core release: 1. Percentage of transaction=
 getting replaced 2. Miners profit (Fee for replaced Tx - Fee for original =
Tx)
>
> Yes, I would be interested too to have those metrics once full-rbf is ava=
ilable in a bitcoin core release. I think that's something every full-rbf c=
urious node operator could observe on its own with a few more loggers, at l=
east for the first metric.
>
> > Can you explain how p2p coinjoin is affected with mempool DoS vector wi=
th some examples? What is considered a p2p coinjoin? Joinmarket or [Stonewa=
ll][1]?
>
> I don't remember the Joinmarket code right now and I don't know the ins a=
nd outs of Samourai coinjoin as I'm not sure the code is open source. Thoug=
h let's say for a p2p coinjoin as one you can build once you have implement=
ed LN's interactive construction protocol [0].
>
> [0] https://github.com/lightning/bolts/pull/851
>
> Here the DoS attack situation :
> - Alice, Bob and Caroll would like to coinjoin 3 inputs to 3 outputs
> - Each of the input is singly controlled by one party, e.g Alice owns inp=
ut A, Bob owns input B, ...
> - Alice, Bob and Caroll exchanges a PSBT to build a multi-party funded tr=
ansaction (the coinjoin_tx)
> - Alice is elected as the multi-party transaction broadcaster once the si=
gnatures have been exchanged
> - The block feerate is around 10sat/vb
> - One of the transaction input signals opt-in RBF, the transaction is att=
ached a compelling feerate 10sat/vb
> - Caroll broadcasts a double-spend of her own input C, the double-spend i=
s attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF
> - Alice broadcasts the multi-party transaction, it is rejected by the net=
work mempools because Alice double-spend is already present
> - Two alternatives are offered to the coinjoin participants :
>
> Alternative A)
> - They estimate the multi-party feerate as not high enough
> - They fee-bump at 20sat/vb
> - Caroll double-spend one of the input of her malicious double-spend to e=
ject it from the network mempools
> - The multi-party transaction is confirmed at a block feerare far above w=
hat was necessary
> - Alice, Bob, Caroll have loss fee-bumping value without compensation
> - Note, even if Caroll is attacker and assuming the fee-bumping burden is=
 fairly spread among participants, the economic loss inflicted is asymmetri=
c
>
> Alternative B)
> - They wait until some time-out
> - They double-spend their own inputs, Alice double-spend utxo A, Bob doub=
le-spend utxo B
> - They wasted the timevalue of their inputs for the time-out delay
> - Note, even if Caroll is attacker and loss some timevalue too, the econo=
mic loss inflicted is asymmetric
>
> Let me know if you see any error or wrong in this DoS scenario exposure. =
I believe it's fairly simple to execute
> for a medium-skilled attacker.
>
> Antoine
>
> Le ven. 17 juin 2022 =C3=A0 00:54, alicexbt <alicexbt@protonmail.com> a =
=C3=A9crit :
>
> > Hi Antoine,
> >
> >
> >
> > > One could list the operating system on which is running your Lightnin=
g process or the compiler toolchain turning out your Lightning source code =
in a binary artifact. Some weird kernel's memory mapping change could allow=
 access to your channel funding keys, _without_ breaking the Bitcoin consen=
sus rules [0].
> >
> > Lets consider there are 2 users with name Bob (normal LN user) and Caro=
l (attacker running LN node) which I will use in this email for examples. I=
n this case Bob and Carol can manage security of their OS and it is not aff=
ected by others using vulnerable systems or OS.
> >
> >
> > > Moreover, your Lightning node is also relying on the existence of a g=
lobal Internet allowing your HTLC transaction to flow from your physical ho=
st to the crowd of transactions confirming in the blockchain. Due to this "=
protocol assumption" your channel balance would be vulnerable to any change=
 in your ISP routing policy, e.g refusing to accept your IPV4 traffic by a =
sudden desiderata to impose an IPV6 supremacy. Still _without_ breaking the=
 Bitcoin consensus rules. Of course, the odds of your ISP operator adopting=
 this behavior are really low, mostly because your operator has to bind to =
social and economic constraints to stay in business.
> >
> > The odds are low as you said, this can be managed by Bob and Carol beca=
use they can use a better ISP. Others using ISP with some issues may not af=
fect their LN usage.
> >
> >
> > > And I believe this imperative to stay in business is certainly not ab=
sent in the incentives of the Bitcoin node operators. You're free to run an=
y policy on your node, especially one hardening the safety of your operatio=
ns beyond the default one. However, if you start to a transaction-relay non=
-compatible with miner incentives, you won't have an efficient view of the =
blockspace demand, and from then won't be able to offer compelling feerates=
 to execute your business transactions to satisfy your client needs. Or you=
 won't consolidate your wallet UTXOs at times of low-demand. Indeed, a sane=
 visibility of the mempools might not be critical now for your Bitcoin oper=
ations, but this is not likely to become true with miner's coinbase reward =
lowering with time and the system security relying on a fruitful fee market=
.
> >
> > Bob might use full-rbf as its suggested by LN developers for secure LN =
usage and better for miners. Carol could use a different RBF policy for som=
e nodes and mining. In this case Bob may get affected at some point because=
 of Carol's choice to use a different RBF policy which was not true above.
> >
> >
> >
> > > So assuming there is a significant number of economically rational en=
tities running p2p nodes, I think it's a reasonable assumption for Lightnin=
g developers that a policy maximizing miner's income and economic nodes ope=
rations will be widely run on the p2p network, and therefore lay its securi=
ty model on that. When there is a gap between the economically optimal poli=
cy (full-rbf) and the effectively deployed one (optin), and this gap consti=
tutes a flaw for exploitation, I believe it's better to fix it.
> >
> > Agree with the assumption there is nothing wrong in experimenting with =
a new RBF policy (non-default) if that helps some users and projects.
> >
> >
> > > If you have a different mode of thinking w.r.t how we should design p=
rotocol in a trust-minimized, open, adversarial environment such as Bitcoin=
, I'm curious to listen to it.
> >
> > Allowing users to create different mempool policies is great. My though=
t process is to code for happy path, where X policy is expected for replace=
ment and edge cases where Y policy or no policy would be used. Users can tr=
y out different policies and even act as attackers. This is also true for o=
ther things in mempool, 'spkreuse=3Dconflict' prevents address reuse in the=
 mempool when using knots. If I assume that address reuse is always relayed=
, this could become a problem if some users and miners adopt this setting i=
n their mempool.
> >
> >
> > > Of course not. If you deliver any critical software, you should attac=
h a solid manual explaining all the corner cases and rough edges. Even bett=
er would be to enshrine the manual directly in your software API to minimiz=
e the footgunish behaviors. E.g, with any ECC library, forbidding to reuse =
nonces. If your user still ignores or misread the manual and provides an in=
secure input, there is not that much you can do.
> >
> > Agree with the documentation as it helps users.
> >
> >
> > > Given there are like 17000 public LN nodes, if half of them adopt ful=
l-rbf it should give already a good number of full-rbf transaction-relay ro=
utes across the p2p network graph. When we're there, we can measure and thi=
nk more about how to tune the full-rbf sub-topology.
> >
> > Sounds good.
> >
> >
> > > Because it's breaking the reliability and security of their use-cases=
. Use-cases which didn't exist a few years ago. The mempool DoS vector is d=
escribed here [4]. To the best of my understanding, it might affect a bunch=
 of use-cases, such as dual-funded channels, on-chain DLCs, p2p coinjoins, =
batched submarine swaps out. With the attack described, the honest set of u=
sers might not have visibility of the network mempools that there is a mali=
cious, low-cost, opt-out double-spend preventing the propagation of their m=
ulti-party transaction. With the existence of a full-rbf transaction-relay =
topology, the multi-party transaction is able to replace the optout.
> >
> > This makes sense and I would be interested to follow two things once fu=
ll-rbf is available in a bitcoin core release: 1. Percentage of transaction=
 getting replaced 2. Miners profit (Fee for replaced Tx - Fee for original =
Tx)
> >
> >
> > Can you explain how p2p coinjoin is affected with mempool DoS vector wi=
th some examples? What is considered a p2p coinjoin? Joinmarket or [Stonewa=
ll][1]?
> >
> >
> > > Selecting a full-node to underpin any serious Bitcoin infrastructure =
or secure a significant stack of coins should be submitted to a fully-fledg=
ed decision-making process. Many factors are likely to matter such as the l=
evel of activity of the contributor community, the chain of trust w.r.t dep=
endencies, the security incident track records, the quality of the document=
ation, the exhaustivity and robustness of the set of features, ...
> >
> > I agree that contributor community and documentation could be improved =
in Knots.
> >
> >
> > > Developers are also Bitcoin users, and they're modifying the software=
 to suit their use-case needs. And that's exactly the purpose of the 'full-=
rbf' PR I'm proposing, aiming to propose a "good" policy for a Lightning no=
de, without actually seeking to change the default.
> >
> > I like that default still remains opt-in and cool with different polici=
es being tried out if that helps some users.
> >
> >
> > > If they're parties interested in implementing more RBF policy options=
 in Bitcoin Core, I think they're free to propose such changes and invest t=
he engineering effort to do so. If you're interested in advancing the state=
 of policy options in Bitcoin Core, there are a lot of interesting resource=
s available and communities to encourage you in the learning process to con=
tribute to the codebase [6].
> >
> > Thanks for sharing the link. I would love to see 5 RBF policies availab=
le to use in bitcoin core. I have already tried experimenting with a few on=
 regtest and will try to open pull request if there are enough people inter=
ested to test it on other chains (testnet3, signet, mainnet)
> >
> >
> > [1]: https://docs.samourai.io/spend-tools
> >
> >
> >
> >
> > /dev/fd0
> >
> >
> >
> > Sent with Proton Mail secure email.
> >
> > ------- Original Message -------
> > On Friday, June 17th, 2022 at 7:04 AM, Antoine Riard <antoine.riard@gma=
il.com> wrote:
> >
> >
> > > Hi alicexbt,
> > >
> > >
> > >
> > > Thanks for taking time to review the pull request,
> > >
> > >
> > >
> > > > 1)If something relies on a policy which can be changed without brea=
king consensus rules, how is it secure in any case with or without full rbf=
?
> > >
> > >
> > >
> > > Your Lightning node software relies on far more software and hardware=
 components than the transaction-relay p2p network. One could list the oper=
ating system on which is running your Lightning process or the compiler too=
lchain turning out your Lightning source code in a binary artifact. Some we=
ird kernel's memory mapping change could allow access to your channel fundi=
ng keys, _without_ breaking the Bitcoin consensus rules [0]. Moreover, your=
 Lightning node is also relying on the existence of a global Internet allow=
ing your HTLC transaction to flow from your physical host to the crowd of t=
ransactions confirming in the blockchain. Due to this "protocol assumption"=
 your channel balance would be vulnerable to any change in your ISP routing=
 policy, e.g refusing to accept your IPV4 traffic by a sudden desiderata to=
 impose an IPV6 supremacy. Still _without_ breaking the Bitcoin consensus r=
ules. Of course, the odds of your ISP operator adopting this behavior are r=
eally low, mostly because your operator has to bind to social and economic =
constraints to stay in business.
> > >
> > >
> > >
> > > And I believe this imperative to stay in business is certainly not ab=
sent in the incentives of the Bitcoin node operators. You're free to run an=
y policy on your node, especially one hardening the safety of your operatio=
ns beyond the default one. However, if you start to a transaction-relay non=
-compatible with miner incentives, you won't have an efficient view of the =
blockspace demand, and from then won't be able to offer compelling feerates=
 to execute your business transactions to satisfy your client needs. Or you=
 won't consolidate your wallet UTXOs at times of low-demand. Indeed, a sane=
 visibility of the mempools might not be critical now for your Bitcoin oper=
ations, but this is not likely to become true with miner's coinbase reward =
lowering with time and the system security relying on a fruitful fee market=
.
> > >
> > >
> > >
> > > So assuming there is a significant number of economically rational en=
tities running p2p nodes, I think it's a reasonable assumption for Lightnin=
g developers that a policy maximizing miner's income and economic nodes ope=
rations will be widely run on the p2p network, and therefore lay its securi=
ty model on that. When there is a gap between the economically optimal poli=
cy (full-rbf) and the effectively deployed one (optin), and this gap consti=
tutes a flaw for exploitation, I believe it's better to fix it.
> > >
> > >
> > >
> > > If you have a different mode of thinking w.r.t how we should design p=
rotocol in a trust-minimized, open, adversarial environment such as Bitcoin=
, I'm curious to listen to it.
> > >
> > >
> > >
> > > > If I write a python script that expects user to enter char 'a' or '=
b' but user can enter 'c' and there is no code to handle exceptions or othe=
r chars, will it be secure?
> > >
> > >
> > >
> > > Of course not. If you deliver any critical software, you should attac=
h a solid manual explaining all the corner cases and rough edges. Even bett=
er would be to enshrine the manual directly in your software API to minimiz=
e the footgunish behaviors. E.g, with any ECC library, forbidding to reuse =
nonces. If your user still ignores or misread the manual and provides an in=
secure input, there is not that much you can do.
> > >
> > >
> > >
> > > By analogy, I believe that's the same with Lightning. One recommendat=
ion of the deployment manual would be to be always connected to a full-rbf =
transaction-relay topology. Defaulting to this rule and your node exposes f=
ar more surface of attacks. Assuming the manual has been well-written (big =
assumption!), I don't think the system designer would be to blame.
> > >
> > >
> > >
> > > That said, one issue to confess with current Lightning is our lack of=
 understanding of what should be figured out in the LN user manual for safe=
 operations. I would say that's an active area of research [1] [2] [3]
> > >
> > >
> > >
> > > > 2)full-rbf is not default in the 2 open pull requests, so this expe=
riment still relies on users changing RBF policies manually. If majority of=
 nodes use default opt-in policy, how would this affect vulnerable projects=
?
> > >
> > >
> > >
> > > If we define the goal as ensuring there is a significant number of tr=
ansaction-relay routes between the L2s nodes requiring full-rbf and the set=
 of miners supporting this policy, and the set of miners is populated enoug=
h, there is no need to convince the majority of nodes operators to switch t=
o full-rbf.
> > >
> > >
> > >
> > > Beyond landing the 'full-rbf' pull request, in pursuit of a partial f=
ull-rbf deployment, I'm thinking of reaching out to Lightning vendors to re=
commend running LN nodes operators run their full-node with the setting ena=
bled. And also to few mining pool operators to advocate the potential incre=
ase in their income.
> > >
> > >
> > >
> > > Given there are like 17000 public LN nodes, if half of them adopt ful=
l-rbf it should give already a good number of full-rbf transaction-relay ro=
utes across the p2p network graph. When we're there, we can measure and thi=
nk more about how to tune the full-rbf sub-topology.
> > >
> > >
> > >
> > > > 2-3% transactions are replaced with opt-in RBF, if someone did not =
replace earlier why would they do it with full RBF?
> > >
> > >
> > >
> > > Because it's breaking the reliability and security of their use-cases=
. Use-cases which didn't exist a few years ago. The mempool DoS vector is d=
escribed here [4]. To the best of my understanding, it might affect a bunch=
 of use-cases, such as dual-funded channels, on-chain DLCs, p2p coinjoins, =
batched submarine swaps out. With the attack described, the honest set of u=
sers might not have visibility of the network mempools that there is a mali=
cious, low-cost, opt-out double-spend preventing the propagation of their m=
ulti-party transaction. With the existence of a full-rbf transaction-relay =
topology, the multi-party transaction is able to replace the optout.
> > >
> > >
> > >
> > > None of those use-cases were deployed a few years ago, and the unders=
tanding of the interactions with the mempool policy is still nascent among =
their operators. However, if we assume that layering is a way to grow the B=
itcoin ecosystem, as I do, it is reasonable to expect they will constitute =
a notable share of the Bitcoin transaction traffic during the next decade.
> > >
> > >
> > >
> > > > I am not opposed to full-rbf; rather, I am opposed to the notion th=
at full-rbf will solve all problems
> > >
> > >
> > >
> > > I wished we had a magic Silver Bullet (tm) solving all the Bitcoin pr=
oblems...
> > >
> > >
> > >
> > > I'm only advocating a partial full-rbf deployment to solve a real pre=
cise security issue affecting multi-party funded transactions. That said, f=
ull-rbf is far from solving the known set of problems affecting the L2s due=
 to interactions with network mempools. E,g, see package relay motivation [=
5]
> > >
> > >
> > >
> > > > I would suggest users to try Bitcoin Knots instead which already ha=
s an option to disable all RBF policies if required, opt-in and full RBF po=
licy.
> > >
> > >
> > >
> > > Selecting a full-node to underpin any serious Bitcoin infrastructure =
or secure a significant stack of coins should be submitted to a fully-fledg=
ed decision-making process. Many factors are likely to matter such as the l=
evel of activity of the contributor community, the chain of trust w.r.t dep=
endencies, the security incident track records, the quality of the document=
ation, the exhaustivity and robustness of the set of features, ...
> > >
> > >
> > >
> > > This process might take tens of hours, to be duplicated by the number=
 of node operators who would have to do the full-node vending switch. If yo=
u consider the cognitive cost at the level of the Bitcoin ecosystem, it's f=
ar less costly to implement and review a few lines of codes in Bitcoin Core=
.
> > >
> > >
> > >
> > > > Developers should provide basic RBF policy options rather than atte=
mpting to define what constitutes a good policy and removing the ability to=
 disable something when necessary.
> > >
> > >
> > >
> > > Of course, this statement assumes there is a clear line between the d=
evelopers and the users. Developers are also Bitcoin users, and they're mod=
ifying the software to suit their use-case needs. And that's exactly the pu=
rpose of the 'full-rbf' PR I'm proposing, aiming to propose a "good" policy=
 for a Lightning node, without actually seeking to change the default. If t=
hey're parties interested in implementing more RBF policy options in Bitcoi=
n Core, I think they're free to propose such changes and invest the enginee=
ring effort to do so. If you're interested in advancing the state of policy=
 options in Bitcoin Core, there are a lot of interesting resources availabl=
e and communities to encourage you in the learning process to contribute to=
 the codebase [6].
> > >
> > >
> > >
> > > Antoine
> > >
> > >
> > >
> > > [0] https://dirtycow.ninja
> > >
> > > [1] https://github.com/t-bast/lightning-docs/blob/master/pinning-atta=
cks.md
> > >
> > > [2] https://arxiv.org/pdf/2006.01418.pdf
> > >
> > > [3] https://arxiv.org/pdf/2006.08513.pdf
> > >
> > > [4] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-Ma=
y/003033.html
> > >
> > > [5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/=
020493.html
> > >
> > > [6] https://www.summerofbitcoin.org
> > >
> > >
> > > Le jeu. 16 juin 2022 =C3=A0 00:15, alicexbt <alicexbt@protonmail.com>=
 a =C3=A9crit :
> > >
> > > > Hi Antoine,
> > > >
> > > >
> > > > Thanks for opening the pull request to add support for full-rbf in =
Bitcoin Core. I have a disagreements with the approach and questions.
> > > >
> > > >
> > > > > Recent discussions among LN devs have brought back on the surface=
 concerns about the security of multi-party funded transactions (coinjoins,=
 dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-=
fruit, naive DoS vector playable against the funding flow of any such const=
ruction due to the lack of existent full-rbf transaction-relay topology on =
today's p2p network [0] [1].
> > > >
> > > > 1)If something relies on a policy which can be changed without brea=
king consensus rules, how is it secure in any case with or without full rbf=
? If I write a python script that expects user to enter char 'a' or 'b' but=
 user can enter 'c' and there is no code to handle exceptions or other char=
s, will it be secure?
> > > >
> > > > 2)full-rbf is not default in the 2 open pull requests, so this expe=
riment still relies on users changing RBF policies manually. If majority of=
 nodes use default opt-in policy, how would this affect vulnerable projects=
?
> > > >
> > > >
> > > > > If you're a mining operator looking to increase your income, you =
might be interested to experiment with full-rbf as a policy.
> > > >
> > > > Miners can only increase their income if users replace transactions=
. 2-3% transactions are replaced with opt-in RBF, if someone did not replac=
e earlier why would they do it now even with full RBF? Or even if we add so=
me users in it who could not signal for some reasons, do you think it would=
 be anything above 5%?
> > > >
> > > >
> > > > > If you're a Bitcoin user or business and you don't like full-rbf,=
 please express an opinion on how it might affect your software/operations.=
 I'm always interested to learn more about mempool and transaction-relay in=
teractions with upper-layers and applications and to listen to feedback in =
those areas, and I guess a lot of other Bitcoin researchers/devs too. I kno=
w there have been a lot of concerns about full-rbf in the past, however I b=
elieve the Bitcoin ecosystem has matured a lot since then.
> > > >
> > > > I am not opposed to full-rbf; rather, I am opposed to the notion th=
at full-rbf will solve all problems and the lack of basic options in Bitcoi=
n Core to employ/disable different RBF policies. There is also a speculatio=
n about making full RBF default in an year which isn't relevant to discuss =
at this point without trying different RBF policies.
> > > >
> > > > I would suggest users to try Bitcoin Knots instead which already ha=
s an option to disable all RBF policies if required, opt-in and full RBF po=
licy. This can also be done using GUI if not familiar with config option `m=
empoolreplacement`.
> > > >
> > > > The rationale in PR #16171 was insufficient to justify removing it =
in the first place, had 2 NACKs and was reopened to merge it. Why bother wi=
th a few lines of code that may allow someone disable it if required in loc=
al mempool since it's only useful when a big percentage of miners utilize i=
t and essentially underused according to the PR author? Developers should p=
rovide basic RBF policy options rather than attempting to define what const=
itutes a good policy and removing the ability to disable something when nec=
essary.
> > > >
> > > >
> > > > /dev/fd0
> > > >
> > > >
> > > > Sent with Proton Mail secure email.
> > > >
> > > > ------- Original Message -------
> > > > On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-d=
ev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > >
> > > >
> > > > > Hi list,
> > > > >
> > > > > Recent discussions among LN devs have brought back on the surface=
 concerns about the security of multi-party funded transactions (coinjoins,=
 dual-funded LN channels, on-chain DLCs, ...). It turns out there is a low-=
fruit, naive DoS vector playable against the funding flow of any such const=
ruction due to the lack of existent full-rbf transaction-relay topology on =
today's p2p network [0] [1]. While it does not consist in a direct loss of =
funds, if exploited well I think it's annoying enough to inflict significan=
t timevalue loss or fee-bumping waste
> > > > > to the future providers or distributed swarm of users doing multi=
-party funded transactions. Of course, it can be fixed one layer above by i=
ntroducing either fidelity bonds or a reliable centralized coordinator, tho=
ugh at the price of an overhead per-participant ressources cost and loss in=
 system openness [1].
> > > > >
> > > > > For that reason, I believe it would be beneficial to the flourish=
ing of multi-party funded transactions to fix the Dos vector by seeing a su=
bset of the network running full-rbf and enabling propagation of honest mul=
ti-party transactions to the interested miners, replacing potential non-sig=
naling double-spend from a malicious counterparty. Moving towards that dire=
ction, I've submitted a small patch against Bitcoin Core enabling it to tur=
n on full-rbf as a policy, still under review [3]. The default setting stay=
s **false**, i.e keeping opt-in RBF as a default replacement policy. I've s=
tarted to run the patch on a public node at 146.190.224.15.
> > > > >
> > > > > If you're a node operator curious to play with full-rbf, feel fre=
e to connect to this node or spawn up a toy, public node yourself. There is=
 a ##uafrbf libera chat if you would like information on the settings or lo=
oking for full-rbf friends (though that step could be automated in the futu=
re by setting up a dedicated network bit and reserving a few outbound slots=
 for them).
> > > > >
> > > > > If you're a mining operator looking to increase your income, you =
might be interested to experiment with full-rbf as a policy. Indeed, in the=
 future I believe the multi-party transactions issuers who need full-rbf to=
 secure their funding flow should connect by default to full-rbf peers. One=
 can conjecture that their transactions are likely to be more compelling in=
 their feerate as their liquidity needs are higher than the simple transact=
ion. For today, I think we have really few standards and bitcoin softwares =
relying on multi-party funded transactions [4].
> > > > >
> > > > > If you're a Bitcoin user or business and you don't like full-rbf,=
 please express an opinion on how it might affect your software/operations.=
 I'm always interested to learn more about mempool and transaction-relay in=
teractions with upper-layers and applications and to listen to feedback in =
those areas, and I guess a lot of other Bitcoin researchers/devs too. I kno=
w there have been a lot of concerns about full-rbf in the past, however I b=
elieve the Bitcoin ecosystem has matured a lot since then.
> > > > >
> > > > > Any mistakes or missing context is my own.
> > > > >
> > > > > Cheers,
> > > > > Antoine
> > > > >
> > > > > [0] For more info about replace-by-fee, see https://bitcoinops.or=
g/en/topics/replace-by-fee/
> > > > >
> > > > > [1] For more details about the DoS vector, see https://lists.linu=
xfoundation.org/pipermail/lightning-dev/2021-May/003033.html
> > > > >
> > > > > [2] E.g I think it does not affect the Lightning Pool service, as=
 there is a preliminary step where the participant funds are locked first i=
n a 2-of-2 with the coordinator before being committed in the multi-party b=
atch transaction.
> > > > >
> > > > > [3] https://github.com/bitcoin/bitcoin/pull/25353
> > > > >
> > > > > [4] E.g DLCs : https://github.com/discreetlogcontracts/dlcspecs/b=
lob/master/Transactions.md ; Lightning dual-funded channel : https://github=
.com/lightning/bolts/pull/851