path: root/cb/c538eb7918b54e7e7e0c77abb5603a5ee20772

Return-Path: <antoine.riard@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1E9B4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jun 2022 23:43:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id D5AEE41BBB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jun 2022 23:43:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D5AEE41BBB
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=NhnZhrC2
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.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,
 HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.199,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id zku1kODpVzba
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jun 2022 23:43:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D753841BBA
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com
 [IPv6:2607:f8b0:4864:20::d2d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id D753841BBA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jun 2022 23:43:35 +0000 (UTC)
Received: by mail-io1-xd2d.google.com with SMTP id c189so15927819iof.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jun 2022 16:43:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=1Fucg6AbRDBG5t9MwLH6NkpwsOGWVoZ0311s85xJB2g=;
 b=NhnZhrC2bUhRNIOoj7KV1NLOvzVov8KFyVyl/l5GyBuiv/qvr/f4tYE9tG1jU3lwRz
 Yc6i6e0qfjCsFSQOTzI9xHPUgBcCf9vCgcL4FyYu81NMAAWfz5YnXucS0MrJiiL0xVqw
 MFjZZNhOigJgtfyVNcmeatQWAXOdcat0R5wZZcpX6WaEAyI8ukZXyikMWfKfj5LR5+DW
 +0ZpTUMjEbrbSL2DXXZIum6RaX+a6U2PhvakhHHf9I97tJl4KIIUIpMs5X7YkumjoY9p
 ejmVxLfMn3VmgW4/29oqO4+/0JXJpwzxhZpWDFVQWYwTn/3c74xUY1a08Xp3jREmOyuJ
 l2BQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=1Fucg6AbRDBG5t9MwLH6NkpwsOGWVoZ0311s85xJB2g=;
 b=JOAMSolHmn9Al9m6PHRCyRQt42mOH2Iuy3V6wEcP0HbaFOaM86D4osjDIGXiUSoTp1
 VpDIt8joHfwU1eX3X5Bu1Zk+9tYPPBsTNWhSkmBGfxJRoxQoJbco89JB9ojG2WS3JkLO
 ebsS3vX4tkcoTe6UvlJuq1iiPIcGEuc8QHV0Ov7pCpMiXhFhuNsNcQJXLZ1r7XM58bgX
 rvKWqLMepHoE0aPmZB6Si6kW9VqczKz+vqnW1b9ioADccdfxc02bJuCay/WaPXrkKlkY
 IIAeDRZvw/osPyg3Lcz0SV3b7KSJ6FUVorPghFlAeMSYX9/ynJH3sY/WBUsOTylSqrro
 jzVA==
X-Gm-Message-State: AJIora8VEu4x9ZqVOrPzWO8WF9Aqytg+cLu5+AumH62gfp3LEfy4n1kn
 VD/mW61DEG+AfdM3tzBHeQSqWJymMW9JpKyCMmUx+ojQt9A=
X-Google-Smtp-Source: AGRyM1tF8DrIif15kRJuXucbO5a6dmR803ajLkU/OKQeiu+jDRoGofMxtZWRYGHWijQDlpN4bmTEPyKZtqgoErGGwF8=
X-Received: by 2002:a05:6638:24c7:b0:331:f0ae:3a17 with SMTP id
 y7-20020a05663824c700b00331f0ae3a17mr421666jat.238.1655855014760; Tue, 21 Jun
 2022 16:43:34 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <RJEFmrnjbzKQCBr4L7ebwBLzg7QHGXlaE19zj6jfkxL6xjfodgbfssZBQSYxm783Y4X5awuhL9Gj8IaBc4npE2oh3d1xoudKTrSsJ-dk0VQ=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 21 Jun 2022 19:43:23 -0400
Message-ID: <CALZpt+HXB=xh3qtxJFM7yUzRu1uj-pPtLQmT=5QV0dNfVuTpfQ@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000f4550a05e1fdc99a"
X-Mailman-Approved-At: Wed, 22 Jun 2022 00:02:05 +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: Tue, 21 Jun 2022 23:43:40 -0000

--000000000000f4550a05e1fdc99a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

HI alicexbt,

> Lets consider there are 2 users with name Bob (normal LN user) and Carol
(attacker running LN node) which I will use in this email for examples. In
this case Bob and Carol can manage security of their OS and it is not
affected 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 review
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
because they can use a better ISP. Others using ISP with some issues may
not affect their LN usage.

Sure, though as I would like to underscore being dependent on a Bitcoin
node policy and being dependent on a ISP internet traffic routing policy
could 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-resistant tx-relay network back to economically-rational miners,
you're free to not 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
some 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 p2p
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
game are economically-rational, and as such incentived to pick up a policy
such as full-rbf. I know the term "economically-rational" is poorly defined
here, 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 thought
process is to code for happy path, where X policy is expected for
replacement and edge cases where Y policy or no policy would be used. Users
can try out different policies and even act as attackers. This is also true
for other things in mempool, 'spkreuse=3Dconflict' prevents address reuse i=
n
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 in 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
interested in more features, they're always free to implement themselves.
Really, 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 high degree of software literacy among bitcoiners.

> This makes sense and I would be interested to follow two things once
full-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
available in a bitcoin core release. I think that's something every
full-rbf curious node operator could observe on its own with a few more
loggers, at least for the first metric.

> Can you explain how p2p coinjoin is affected with mempool DoS vector with
some examples? What is considered a p2p coinjoin? Joinmarket or
[Stonewall][1]?

I don't remember the Joinmarket code right now and I don't know the ins and
outs of Samourai coinjoin as I'm not sure the code is open source. Though
let's say for a p2p coinjoin as one you can build once you have implemented
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 input
A, Bob owns input B, ...
- Alice, Bob and Caroll exchanges a PSBT to build a multi-party funded
transaction (the coinjoin_tx)
- Alice is elected as the multi-party transaction broadcaster once the
signatures have been exchanged
- The block feerate is around 10sat/vb
- One of the transaction input signals opt-in RBF, the transaction is
attached a compelling feerate 10sat/vb
- Caroll broadcasts a double-spend of her own input C, the double-spend is
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
network 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
eject it from the network mempools
- The multi-party transaction is confirmed at a block feerare far above
what 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 asymmetric

Alternative B)
- They wait until some time-out
- They double-spend their own inputs, Alice double-spend utxo A, Bob
double-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
economic 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 Lightning
> process or the compiler toolchain turning out your Lightning source code
> in a binary artifact. Some weird kernel's memory mapping change could all=
ow
> access to your channel funding keys, _without_ breaking the Bitcoin
> consensus rules [0].
>
>
> Lets consider there are 2 users with name Bob (normal LN user) and Carol
> (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
> affected by others using vulnerable systems or OS.
>
> Moreover, your Lightning node is also relying on the existence of a
> global Internet allowing your HTLC transaction to flow from your physical
> host 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 yo=
ur
> 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 becaus=
e
> they can use a better ISP. Others using ISP with some issues may not affe=
ct
> their LN usage.
>
> And I believe this imperative to stay in business is certainly not absent
> in the incentives of the Bitcoin node operators. You're free to run any
> 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 y=
our
> Bitcoin operations, 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
> some 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 tru=
e
> above.
>
>
> So assuming there is a significant number of economically rational
> entities running p2p nodes, I think it's a reasonable assumption for
> Lightning developers that a policy maximizing miner's income and economic
> nodes operations will be widely run on the p2p network, and therefore lay
> its security model on that. When there is a gap between the economically
> optimal policy (full-rbf) and the effectively deployed one (optin), and
> this gap constitutes 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
> protocol 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 thought
> process is to code for happy path, where X policy is expected for
> replacement and edge cases where Y policy or no policy would be used. Use=
rs
> can try out different policies and even act as attackers. This is also tr=
ue
> for other 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 in their mempool.
>
> Of course not. If you deliver any critical software, you should attach a
> solid manual explaining all the corner cases and rough edges. Even better
> would be to enshrine the manual directly in your software API to minimize
> 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
> insecure 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 full-rb=
f
> it should give already a good number of full-rbf transaction-relay routes
> across the p2p network graph. When we're there, we can measure and think
> 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
> described 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 users might not have visibility of the network mempools
> that there is a malicious, low-cost, opt-out double-spend preventing the
> propagation of their multi-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
> full-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 with
> some examples? What is considered a p2p coinjoin? Joinmarket or
> [Stonewall][1]?
>
> Selecting a full-node to underpin any serious Bitcoin infrastructure or
> secure a significant stack of coins should be submitted to a
> fully-fledged decision-making process. Many factors are likely to matter =
such
> as the level of activity of the contributor community, the chain of trust
> w.r.t dependencies, the security incident track records, the quality of
> the documentation, 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 node, without actually seeking to change the default.
>
>
> I like that default still remains opt-in and cool with different policies
> 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 the
> 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 resources=
 available
> and communities to encourage you in the learning process to contribute to
> the codebase [6].
>
>
> Thanks for sharing the link. I would love to see 5 RBF policies available
> 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
> interested to test it on other chains (testnet3, signet, mainnet)
>
>
> [1]: https://docs.samourai.io/spend-tools
>
>
> /dev/fd0
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Friday, June 17th, 2022 at 7:04 AM, Antoine Riard <
> antoine.riard@gmail.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 breaking
> 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
> operating system on which is running your Lightning process or the compil=
er
> 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 consensus rules [0].
> Moreover, your Lightning node is also relying on the existence of a
> global Internet allowing your HTLC transaction to flow from your physical
> host 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 yo=
ur
> ISP operator adopting this behavior are really 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 absent
> in the incentives of the Bitcoin node operators. You're free to run any
> 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 y=
our
> Bitcoin operations, 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
> entities running p2p nodes, I think it's a reasonable assumption for
> Lightning developers that a policy maximizing miner's income and economic
> nodes operations will be widely run on the p2p network, and therefore lay
> its security model on that. When there is a gap between the economically
> optimal policy (full-rbf) and the effectively deployed one (optin), and
> this gap constitutes 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
> protocol 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 other
> chars, will it be secure?
>
>
> Of course not. If you deliver any critical software, you should attach a
> solid manual explaining all the corner cases and rough edges. Even better
> would be to enshrine the manual directly in your software API to minimize
> 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
> insecure input, there is not that much you can do.
>
>
> By analogy, I believe that's the same with Lightning. One recommendation
> 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
> far more surface of attacks. Assuming the manual has been well-written (b=
ig
> 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
> experiment 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
> transaction-relay routes between the L2s nodes requiring full-rbf and the
> set of miners supporting this policy, and the set of miners is populated
> enough, there is no need to convince the majority of nodes operators to
> switch to full-rbf.
>
>
> Beyond landing the 'full-rbf' pull request, in pursuit of a partial
> full-rbf deployment, I'm thinking of reaching out to Lightning vendors to
> recommend running LN nodes operators run their full-node with the setting
> enabled. And also to few mining pool operators to advocate the potential
> increase in their income.
>
>
> Given there are like 17000 public LN nodes, if half of them adopt full-rb=
f
> it should give already a good number of full-rbf transaction-relay routes
> across the p2p network graph. When we're there, we can measure and think
> 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
> described 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 users might not have visibility of the network mempools
> that there is a malicious, low-cost, opt-out double-spend preventing the
> propagation of their multi-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
> understanding of the interactions with the mempool policy is still
> nascent among their operators. However, if we assume that layering is a w=
ay
> to grow the Bitcoin 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 that
> full-rbf will solve all problems
>
>
> I wished we had a magic Silver Bullet (tm) solving all the Bitcoin
> problems...
>
>
> I'm only advocating a partial full-rbf deployment to solve a real precise
> security issue affecting multi-party funded transactions. That said,
> full-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 has an
> option to disable all RBF policies if required, opt-in and full RBF polic=
y.
>
>
> Selecting a full-node to underpin any serious Bitcoin infrastructure or
> secure a significant stack of coins should be submitted to a
> fully-fledged decision-making process. Many factors are likely to matter
> such as the level of activity of the contributor community, the chain of
> trust w.r.t dependencies, the security incident track records, the
> quality of the documentation, 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 you
> consider the cognitive cost at the level of the Bitcoin ecosystem, it's
> far less costly to implement and review a few lines of codes in Bitcoin
> Core.
>
>
> > Developers should provide basic RBF policy options rather than
> attempting 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
> developers and the users. Developers are also Bitcoin users, and they're
> modifying the software to suit their use-case needs. And that's exactly t=
he
> purpose 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 they're parties interested in implementing more RBF policy
> options in Bitcoin Core, I think they're free to propose such changes and
> invest the 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 resources available 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-attacks.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-May/003033=
.html
>
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020493.h=
tml
>
> [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 (coinjoin=
s,
>> 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 suc=
h
>> construction 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 breaking
>> 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 u=
ser
>> can enter 'c' and there is no code to handle exceptions or other chars,
>> will it be secure?
>>
>> 2)full-rbf is not default in the 2 open pull requests, so this experimen=
t
>> still relies on users changing RBF policies manually. If majority of nod=
es
>> use default opt-in policy, how would this affect vulnerable projects?
>>
>> If you're a mining operator looking to increase your income, you might b=
e
>> 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 replace
>> earlier why would they do it now even with full RBF? Or even if we add s=
ome
>> 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
>> interactions with upper-layers and applications and to listen to feedbac=
k
>> in those areas, and I guess a lot of other Bitcoin researchers/devs too.=
 I
>> know there have been a lot of concerns about full-rbf in the past, howev=
er
>> I believe the Bitcoin ecosystem has matured a lot since then.
>>
>>
>> I am not opposed to full-rbf; rather, I am opposed to the notion that
>> 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 speculati=
on
>> 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 has an
>> option to disable all RBF policies if required, opt-in and full RBF poli=
cy.
>> This can also be done using GUI if not familiar with config option
>> mempoolreplacement=E2=80=8B.
>>
>> The rationale in PR #16171 was insufficient to justify removing it in th=
e
>> first place, had 2 NACKs and was reopened to merge it. Why bother with a
>> few lines of code that may allow someone disable it if required in local
>> 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
>> provide basic RBF policy options rather than attempting to define what
>> constitutes a good policy and removing the ability to disable something
>> when necessary.
>>
>>
>> /dev/fd0
>>
>> Sent with Proton Mail <https://proton.me/> secure email.
>>
>> ------- Original Message -------
>> On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-dev <
>> 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 (coinjoin=
s,
>> 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 suc=
h
>> construction 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 significant 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
>> introducing either fidelity bonds or a reliable centralized coordinator,
>> though at the price of an overhead per-participant ressources cost and l=
oss
>> in system openness [1].
>>
>> For that reason, I believe it would be beneficial to the flourishing of
>> multi-party funded transactions to fix the Dos vector by seeing a subset=
 of
>> the network running full-rbf and enabling propagation of honest multi-pa=
rty
>> transactions to the interested miners, replacing potential non-signaling
>> double-spend from a malicious counterparty. Moving towards that directio=
n,
>> I've submitted a small patch against Bitcoin Core enabling it to turn on
>> full-rbf as a policy, still under review [3]. The default setting stays
>> **false**, i.e keeping opt-in RBF as a default replacement policy. I've
>> started 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 free 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
>> looking for full-rbf friends (though that step could be automated in the
>> future by setting up a dedicated network bit and reserving a few outboun=
d
>> slots for them).
>>
>> If you're a mining operator looking to increase your income, you might b=
e
>> interested to experiment with full-rbf as a policy. Indeed, in the futur=
e 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
>> transaction. 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
>> interactions with upper-layers and applications and to listen to feedbac=
k
>> in those areas, and I guess a lot of other Bitcoin researchers/devs too.=
 I
>> know there have been a lot of concerns about full-rbf in the past, howev=
er
>> I believe 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.org/en/topics/replace-by-fee/
>>
>> [1] For more details about the DoS vector, see
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00303=
3.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 in a
>> 2-of-2 with the coordinator before being committed in the multi-party ba=
tch
>> transaction.
>>
>> [3] https://github.com/bitcoin/bitcoin/pull/25353
>>
>> [4] E.g DLCs :
>> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transaction=
s.md
>> ; Lightning dual-funded channel :
>> https://github.com/lightning/bolts/pull/851
>>
>>
>>
>

--000000000000f4550a05e1fdc99a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">HI alicexbt,<br><br>&gt; Lets consider there are 2 users w=
ith name Bob (normal LN user) and Carol (attacker running LN node) which I =
will use in this email for examples. In this case Bob and Carol can manage =
security of their OS and it is not affected by others using vulnerable syst=
ems or OS.<br><br>Yes, I believe my argument was the set of components maki=
ng the security of your LN node is far beyond Bitcoin softwares. Of course,=
 you might review by yourself the millions lines of code entering in the tr=
usted computing base (OS, bootloader, BIOS, device firmwares, essential uti=
lities, ...) on which your cryptocurrency software stack lays out, and as s=
uch exercise an extended span of control on your personal computation. Thou=
gh, while I hope we&#39;ll have more LN node operators doing so, I&#39;m no=
t sure it&#39;s realistic to expect it will be the behavior standard among =
them..<br><br>&gt; The odds are low as you said, this can be managed by Bob=
 and Carol because they can use a better ISP. Others using ISP with some is=
sues may not affect their LN usage.<br><br>Sure, though as I would like to =
underscore being dependent on a Bitcoin node policy and being dependent on =
a ISP internet traffic routing policy could be analyzed as logically equiva=
lent, all things are equal. That said, if your personal risk aversion is to=
o high for the Lightning security model, once it&#39;s well-understood ther=
e is a strong reliance on a censorship-resistant tx-relay network back to e=
conomically-rational miners, you&#39;re free to not use it and satisfy your=
self with the Bitcoin base layer.<br><br>&gt; Bob might use full-rbf as its=
 suggested by LN developers for secure LN usage and better for miners. Caro=
l could use a different RBF policy for some nodes and mining. In this case =
Bob may get affected at some point because of Carol&#39;s choice to use a d=
ifferent RBF policy which was not true above.<br><br>Indeed, your secure LN=
 usage is going to be dependent of the number of p2p network nodes running =
an economically-rational policy like full-rbf. That said, I think it&#39;s =
reasonable to assume that the players of the Bitcoin game are economically-=
rational, and as such incentived to pick up a policy such as full-rbf. I kn=
ow the term &quot;economically-rational&quot; is poorly defined here, and I=
 think it could be interesting for any academic with an economic background=
 to study the incentives of Bitcoin actors.<br><br>&gt; Allowing users to c=
reate different mempool policies is great. My thought process is to code fo=
r happy path, where X policy is expected for replacement and edge cases whe=
re Y policy or no policy would be used. Users can try out different policie=
s and even act as attackers. This is also true for other things in mempool,=
 &#39;spkreuse=3Dconflict&#39; prevents address reuse in the mempool when u=
sing knots. If I assume that address reuse is always relayed, this could be=
come a problem if some users and miners adopt this setting in their mempool=
.<br><br>Agree, I&#39;m all in for people to experiment with mempool polici=
es. Though at the end it&#39;s a software engineering resource question. If=
 users are interested in more features, they&#39;re always free to implemen=
t themselves. Really, the binary distinction developers-vs-users doesn&#39;=
t make sense and if we would like Bitcoin to be successful in the long-term=
, we should promote high degree of software literacy among bitcoiners.<br><=
br>&gt; This makes sense and I would be interested to follow two things onc=
e full-rbf is available in a bitcoin core release: 1. Percentage of transac=
tion getting replaced 2. Miners profit (Fee for replaced Tx - Fee for origi=
nal Tx)<br><br>Yes, I would be interested too to have those metrics once fu=
ll-rbf is available in a bitcoin core release. I think that&#39;s something=
 every full-rbf curious node operator could observe on its own with a few m=
ore loggers, at least for the first metric.<br><br>&gt; Can you explain how=
 p2p coinjoin is affected with mempool DoS vector with some examples? What =
is considered a p2p coinjoin? Joinmarket or [Stonewall][1]?<br><br>I don&#3=
9;t remember the Joinmarket code right now and I don&#39;t know the ins and=
 outs of Samourai coinjoin as I&#39;m not sure the code is open source. Tho=
ugh let&#39;s say for a p2p coinjoin as one you can build once you have imp=
lemented LN&#39;s interactive construction protocol [0].<br><br>[0] <a href=
=3D"https://github.com/lightning/bolts/pull/851">https://github.com/lightni=
ng/bolts/pull/851</a><br><br>Here the DoS attack situation :<br>- Alice, Bo=
b and Caroll would like to coinjoin 3 inputs to 3 outputs<br>- Each of the =
input is singly controlled by one party, e.g Alice owns input A, Bob owns i=
nput B, ...<br>- Alice, Bob and Caroll exchanges a PSBT to build a multi-pa=
rty funded transaction (the coinjoin_tx)<br>- Alice is elected as the multi=
-party transaction broadcaster once the signatures have been exchanged<br>-=
 The block feerate is around 10sat/vb<br>- One of the transaction input sig=
nals opt-in RBF, the transaction is attached a compelling feerate 10sat/vb<=
br>- Caroll broadcasts a double-spend of her own input C, the double-spend =
is attached with a low-fee (1sat/vb) and it does _not_ signal opt-in RBF<br=
>- Alice broadcasts the multi-party transaction, it is rejected by the netw=
ork mempools because Alice double-spend is already present<br>- Two alterna=
tives are offered to the coinjoin participants :<br><br>Alternative A)<br>-=
 They estimate the multi-party feerate as not high enough<br>- They fee-bum=
p at 20sat/vb<br>- Caroll double-spend one of the input of her malicious do=
uble-spend to eject it from the network mempools<br>- The multi-party trans=
action is confirmed at a block feerare far above what was necessary<br>- Al=
ice, Bob, Caroll have loss fee-bumping value without compensation<br>- Note=
, even if Caroll is attacker and assuming the fee-bumping burden is fairly =
spread among participants, the economic loss inflicted is asymmetric<br><br=
>Alternative B)<br>- They wait until some time-out<br>- They double-spend t=
heir own inputs, Alice double-spend utxo A, Bob double-spend utxo B<br>- Th=
ey wasted the timevalue of their inputs for the time-out delay<br>- Note, e=
ven if Caroll is attacker and loss some timevalue too, the economic loss in=
flicted is asymmetric<br><br>Let me know if you see any error or wrong in t=
his DoS scenario exposure. I believe it&#39;s fairly simple to execute<br>f=
or a medium-skilled attacker. <br><br>Antoine<br></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 17 juin 2022 =
=C3=A0=C2=A000:54, alicexbt &lt;<a href=3D"mailto:alicexbt@protonmail.com">=
alicexbt@protonmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:arial;font-si=
ze:14px;color:rgb(34,34,34)">Hi Antoine,</div><div style=3D"font-family:ari=
al;font-size:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:=
arial;font-size:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-fami=
ly:arial;font-size:14px;color:rgb(34,34,34)"><blockquote type=3D"cite" styl=
e=3D"padding:0px 0px 0px 1rem;margin:0px;border-left:4px solid rgb(229,229,=
229);color:rgb(0,0,0);font-family:Arial,&quot;Helvetica Neue&quot;,Helvetic=
a,sans-serif;background-color:rgb(255,255,255)"><div dir=3D"ltr"><p style=
=3D"margin:0px"><span style=3D"font-family:arial,sans-serif">One could list=
 the operating system on which is running your Lightning process or the com=
piler toolchain turning out<span>=C2=A0</span></span><span style=3D"font-fa=
mily:arial,sans-serif">your Lightning source code in a binary artifact. Som=
e weird kernel&#39;s memory mapping change could allow access to<span>=C2=
=A0</span></span><span style=3D"font-family:arial,sans-serif">your channel =
funding keys, _without_ breaking the Bitcoin consensus rules [0].</span></p=
></div></blockquote><br></div><div style=3D"font-family:arial;font-size:14p=
x;color:rgb(34,34,34)">Lets consider there are 2 users with name Bob (norma=
l LN user) and Carol (attacker running LN node) which I will use in this em=
ail for examples. In this case Bob and Carol can manage security of their O=
S and it is not affected by others using vulnerable systems or OS.=C2=A0</d=
iv><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><br>=
</div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><=
blockquote type=3D"cite" style=3D"padding:0px 0px 0px 1rem;margin:0px;borde=
r-left:4px solid rgb(229,229,229);color:rgb(0,0,0);font-family:Arial,&quot;=
Helvetica Neue&quot;,Helvetica,sans-serif;background-color:rgb(255,255,255)=
"><div dir=3D"ltr"><p style=3D"margin:0px"><span style=3D"font-family:arial=
,sans-serif">Moreover, your Lightning node is also<span>=C2=A0</span></span=
><span style=3D"font-family:arial,sans-serif">relying on the existence of a=
 global Internet allowing your HTLC transaction to flow from your physical =
host<span>=C2=A0</span></span><span style=3D"font-family:arial,sans-serif">=
to the crowd of transactions confirming in the blockchain. Due to this &quo=
t;protocol assumption&quot; your channel balance<span>=C2=A0</span></span><=
span style=3D"font-family:arial,sans-serif">would be vulnerable to any chan=
ge in your ISP routing policy, e.g refusing to accept your IPV4 traffic by =
a sudden<span>=C2=A0</span></span><span style=3D"font-family:arial,sans-ser=
if">desiderata to impose an IPV6 supremacy. Still _without_ breaking the Bi=
tcoin consensus rules. Of course, the odds of<span>=C2=A0</span></span><spa=
n style=3D"font-family:arial,sans-serif">your ISP operator adopting this be=
havior are really low, mostly because your operator has to bind to social a=
nd<span>=C2=A0</span></span><span style=3D"font-family:arial,sans-serif">ec=
onomic constraints to stay in business.</span></p></div></blockquote><br></=
div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)">The=
 odds are low as you said, this can be managed by Bob and Carol because the=
y can use a better ISP. Others using ISP with some issues may not affect th=
eir LN usage.</div><div style=3D"font-family:arial;font-size:14px;color:rgb=
(34,34,34)"><br></div><div style=3D"font-family:arial;font-size:14px;color:=
rgb(34,34,34)"><blockquote type=3D"cite" style=3D"padding:0px 0px 0px 1rem;=
margin:0px;border-left:4px solid rgb(229,229,229);color:rgb(0,0,0);font-fam=
ily:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-serif;background-color:=
rgb(255,255,255)"><div dir=3D"ltr"><p style=3D"margin:0px"><span style=3D"f=
ont-variant-ligatures:no-common-ligatures"><font face=3D"arial, sans-serif"=
>And I believe this imperative to stay in business is certainly not absent =
in the incentives of the Bitcoin node<span>=C2=A0</span></font></span><span=
 style=3D"font-family:arial,sans-serif">operators. You&#39;re free to run a=
ny policy on your node, especially one hardening the safety of your operati=
ons</span><span style=3D"font-family:arial,sans-serif"><span>=C2=A0</span><=
/span><span style=3D"font-family:arial,sans-serif">beyond the default one. =
However, if you start to a transaction-relay non-compatible with miner ince=
ntives, you<span>=C2=A0</span></span><span style=3D"font-family:arial,sans-=
serif">won&#39;t have an efficient view of the blockspace demand, and from =
then won&#39;t be able to offer compelling feerates<span>=C2=A0</span></spa=
n><span style=3D"font-family:arial,sans-serif">to execute your business tra=
nsactions to satisfy your client needs. Or you won&#39;t consolidate your<s=
pan>=C2=A0</span></span><span style=3D"font-family:arial,sans-serif">wallet=
 UTXOs at<span>=C2=A0</span></span>times<span style=3D"font-family:arial,sa=
ns-serif"><span>=C2=A0</span>of low-demand. Indeed, a sane visibility of th=
e mempools might not be critical now for<span>=C2=A0</span></span><span sty=
le=3D"font-family:arial,sans-serif">your Bitcoin operations, but this is no=
t likely to become true with miner&#39;s coinbase reward lowering with time=
<span>=C2=A0</span></span><span style=3D"font-family:arial,sans-serif">and =
the system security<span>=C2=A0</span></span>relying<span style=3D"font-fam=
ily:arial,sans-serif"><span>=C2=A0</span>on a fruitful fee market.</span></=
p></div></blockquote><br></div><div style=3D"font-family:arial;font-size:14=
px;color:rgb(34,34,34)">Bob might use full-rbf as its suggested by LN devel=
opers for secure LN usage and better for miners. Carol could use a differen=
t RBF policy for some nodes and mining. In this case Bob may get affected a=
t some point because of Carol&#39;s choice to use a different RBF policy wh=
ich was not true above.</div><div style=3D"font-family:arial;font-size:14px=
;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-size:1=
4px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-siz=
e:14px;color:rgb(34,34,34)"><blockquote type=3D"cite" style=3D"padding:0px =
0px 0px 1rem;margin:0px;border-left:4px solid rgb(229,229,229);color:rgb(0,=
0,0);font-family:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-serif;back=
ground-color:rgb(255,255,255)"><div dir=3D"ltr"><p style=3D"margin:0px"><sp=
an style=3D"font-variant-ligatures:no-common-ligatures"><font face=3D"arial=
, sans-serif">So assuming there is a significant number of economically rat=
ional entities running p2p nodes, I think it&#39;s a<span>=C2=A0</span></fo=
nt></span><span style=3D"font-family:arial,sans-serif">reasonable assumptio=
n for Lightning developers that a policy maximizing miner&#39;s income and =
economic nodes<span>=C2=A0</span></span><span style=3D"font-family:arial,sa=
ns-serif">operations will be widely run on the p2p network, and therefore l=
ay its security model on that. When there is a<span>=C2=A0</span></span><sp=
an style=3D"font-family:arial,sans-serif">gap between the economically opti=
mal policy (full-rbf) and the effectively deployed one (optin), and this ga=
p<span>=C2=A0</span></span><span style=3D"font-family:arial,sans-serif">con=
stitutes a flaw for exploitation, I believe it&#39;s better to fix it.</spa=
n></p></div></blockquote><br></div><div style=3D"font-family:arial;font-siz=
e:14px;color:rgb(34,34,34)">Agree with the assumption there is nothing wron=
g in experimenting with a new RBF policy (non-default) if that helps some u=
sers and projects.</div><div style=3D"font-family:arial;font-size:14px;colo=
r:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-size:14px;c=
olor:rgb(34,34,34)"><blockquote type=3D"cite" style=3D"padding:0px 0px 0px =
1rem;margin:0px;border-left:4px solid rgb(229,229,229);color:rgb(0,0,0);fon=
t-family:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-serif;background-c=
olor:rgb(255,255,255)"><div dir=3D"ltr"><p style=3D"margin:0px"><span style=
=3D"font-variant-ligatures:no-common-ligatures"><font face=3D"arial, sans-s=
erif">If you have a different mode of thinking w.r.t how we should design p=
rotocol in a trust-minimized, open,<span>=C2=A0</span></font></span><span s=
tyle=3D"font-family:arial,sans-serif">adversarial</span><span style=3D"font=
-family:arial,sans-serif"><span>=C2=A0</span></span><span style=3D"font-fam=
ily:arial,sans-serif">environment such as Bitcoin, I&#39;m curious to liste=
n to it.</span></p></div></blockquote><br></div><div style=3D"font-family:a=
rial;font-size:14px;color:rgb(34,34,34)"><span>Allowing users to create dif=
ferent mempool policies is great. My thought process is to code for happy p=
ath, where X policy is expected for replacement and edge cases where Y poli=
cy or no policy would be used. Users can try out different policies and eve=
n act as attackers. This is also true for other things in mempool, &#39;spk=
reuse=3Dconflict&#39; prevents address reuse in the mempool when using knot=
s. If I assume that address reuse is always relayed, this could become a pr=
oblem if some users and miners adopt this setting in their mempool.</span><=
/div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><s=
pan><br></span></div><div style=3D"font-family:arial;font-size:14px;color:r=
gb(34,34,34)"><span><blockquote type=3D"cite" style=3D"padding:0px 0px 0px =
1rem;margin:0px;border-left:4px solid rgb(229,229,229);color:rgb(0,0,0);fon=
t-family:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-serif;background-c=
olor:rgb(255,255,255)"><div dir=3D"ltr"><p style=3D"margin:0px"><span style=
=3D"font-variant-ligatures:no-common-ligatures"><font face=3D"arial, sans-s=
erif">Of course not. If you deliver any critical software, you should attac=
h a solid manual explaining all the<span>=C2=A0</span></font></span><span s=
tyle=3D"font-family:arial,sans-serif">corner cases and rough edges. Even be=
tter would be to enshrine the manual directly in your software API<span>=C2=
=A0</span></span><span style=3D"font-family:arial,sans-serif">to minimize t=
he footgunish behaviors. E.g, with any ECC library, forbidding to reuse non=
ces. If your<span>=C2=A0</span></span>user<span style=3D"font-family:arial,=
sans-serif"><span>=C2=A0</span>still ignores or misread the manual and prov=
ides an insecure input, there is<span>=C2=A0</span></span>not that<span sty=
le=3D"font-family:arial,sans-serif"><span>=C2=A0</span>much you can do.</sp=
an></p></div></blockquote><br></span></div><div style=3D"font-family:arial;=
font-size:14px;color:rgb(34,34,34)"><span>Agree with the documentation as i=
t helps users.</span></div><div style=3D"font-family:arial;font-size:14px;c=
olor:rgb(34,34,34)"><span><br></span></div><div style=3D"font-family:arial;=
font-size:14px;color:rgb(34,34,34)"><span><blockquote type=3D"cite" style=
=3D"padding:0px 0px 0px 1rem;margin:0px;border-left:4px solid rgb(229,229,2=
29);color:rgb(0,0,0);font-family:Arial,&quot;Helvetica Neue&quot;,Helvetica=
,sans-serif;background-color:rgb(255,255,255)"><div dir=3D"ltr"><p style=3D=
"margin:0px"><span style=3D"font-variant-ligatures:no-common-ligatures"><fo=
nt face=3D"arial, sans-serif">Given there are like 17000 public LN nodes, i=
f half of them adopt full-rbf it should give<span>=C2=A0</span></font></spa=
n><span style=3D"font-family:arial,sans-serif">already a good number of ful=
l-rbf transaction-relay routes across the p2p network graph.<span>=C2=A0</s=
pan></span><span style=3D"font-family:arial,sans-serif">When we&#39;re ther=
e, we can measure and think more about how to tune the full-rbf sub-topolog=
y.</span></p></div></blockquote><br></span></div><div style=3D"font-family:=
arial;font-size:14px;color:rgb(34,34,34)"><span>Sounds good.</span></div><d=
iv style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><span><br=
></span></div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,3=
4,34)"><span><blockquote type=3D"cite" style=3D"padding:0px 0px 0px 1rem;ma=
rgin:0px;border-left:4px solid rgb(229,229,229);color:rgb(0,0,0);font-famil=
y:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-serif;background-color:rg=
b(255,255,255)"><div dir=3D"ltr"><p style=3D"margin:0px"><span style=3D"fon=
t-variant-ligatures:no-common-ligatures"><font face=3D"arial, sans-serif">B=
ecause it&#39;s breaking the reliability and security of their use-cases. U=
se-cases which didn&#39;t exist<span>=C2=A0</span></font></span><span style=
=3D"font-family:arial,sans-serif">a few years ago. The mempool DoS vector i=
s described here [4]. To the best of my understanding, it might<span>=C2=A0=
</span></span><span style=3D"font-family:arial,sans-serif">affect a bunch o=
f use-cases, such as dual-funded channels, on-chain DLCs, p2p<span>=C2=A0</=
span></span>coinjoins<span style=3D"font-family:arial,sans-serif">, batched=
 submarine<span>=C2=A0</span></span><span style=3D"font-family:arial,sans-s=
erif">swaps out. With the attack described, the honest set of users might n=
ot have visibility of the network<span>=C2=A0</span></span><span style=3D"f=
ont-family:arial,sans-serif">mempools that there is a malicious, low-cost, =
opt-out double-spend preventing the propagation of their multi-party<span>=
=C2=A0</span></span><span style=3D"font-family:arial,sans-serif">transactio=
n. With the existence of a full-rbf transaction-relay topology, the multi-p=
arty transaction<span>=C2=A0</span></span><span style=3D"font-family:arial,=
sans-serif">is able to replace the<span>=C2=A0</span></span>optout<span sty=
le=3D"font-family:arial,sans-serif">.</span></p></div></blockquote><br></sp=
an></div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)=
"><span>This makes sense and I would be interested to follow two things onc=
e full-rbf is available in a bitcoin core release: 1. Percentage of transac=
tion getting replaced 2. Miners profit (Fee for replaced Tx - Fee for origi=
nal Tx)</span></div><div style=3D"font-family:arial;font-size:14px;color:rg=
b(34,34,34)"><span><br></span></div><div style=3D"font-family:arial;font-si=
ze:14px;color:rgb(34,34,34)">Can you explain how p2p coinjoin is affected w=
ith mempool DoS vector with some examples? What is considered a p2p coinjoi=
n? Joinmarket or [Stonewall][1]?</div><div style=3D"font-family:arial;font-=
size:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;fo=
nt-size:14px;color:rgb(34,34,34)"><blockquote type=3D"cite" style=3D"paddin=
g:0px 0px 0px 1rem;margin:0px;border-left:4px solid rgb(229,229,229);color:=
rgb(0,0,0);font-family:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-seri=
f;background-color:rgb(255,255,255)"><div dir=3D"ltr"><p style=3D"margin:0p=
x"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=3D=
"arial, sans-serif">Selecting a full-node to underpin any serious Bitcoin i=
nfrastructure or secure a significant stack of coins<span>=C2=A0</span></fo=
nt></span><span style=3D"font-family:arial,sans-serif">should be submitted =
to a fully-fledged decision-making process. Many factors are likely to<span=
>=C2=A0</span></span>matter<span style=3D"font-family:arial,sans-serif"><sp=
an>=C2=A0</span>such as<span>=C2=A0</span></span><span style=3D"font-family=
:arial,sans-serif">the level of activity of the contributor community, the =
chain of trust w.r.t dependencies, the security incident t</span><span styl=
e=3D"font-family:arial,sans-serif">rack records, the quality of the documen=
tation, the exhaustivity and robustness of the set of features, ...</span><=
/p></div></blockquote><br></div><div style=3D"font-family:arial;font-size:1=
4px;color:rgb(34,34,34)">I agree that contributor community and documentati=
on could be improved in Knots.</div><div style=3D"font-family:arial;font-si=
ze:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font=
-size:14px;color:rgb(34,34,34)"><blockquote type=3D"cite" style=3D"padding:=
0px 0px 0px 1rem;margin:0px;border-left:4px solid rgb(229,229,229);color:rg=
b(0,0,0);font-family:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-serif;=
background-color:rgb(255,255,255)"><div dir=3D"ltr"><p style=3D"margin:0px"=
><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=3D"a=
rial, sans-serif">Developers<span>=C2=A0</span></font></span><span style=3D=
"font-family:arial,sans-serif">are also Bitcoin users, and they&#39;re modi=
fying the software to suit their use-case needs. And that&#39;s exactly<spa=
n>=C2=A0</span></span><span style=3D"font-family:arial,sans-serif">the purp=
ose of the &#39;full-rbf&#39; PR I&#39;m proposing, aiming to propose a &qu=
ot;good&quot; policy for a Lightning node, without actually seeking to chan=
ge the default.</span></p></div></blockquote><br></div><div style=3D"font-f=
amily:arial;font-size:14px;color:rgb(34,34,34)">I like that default still r=
emains opt-in and cool with different policies being tried out if that help=
s some users.</div><div style=3D"font-family:arial;font-size:14px;color:rgb=
(34,34,34)"><br></div><div style=3D"font-family:arial;font-size:14px;color:=
rgb(34,34,34)"><blockquote type=3D"cite" style=3D"padding:0px 0px 0px 1rem;=
margin:0px;border-left:4px solid rgb(229,229,229);color:rgb(0,0,0);font-fam=
ily:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-serif;background-color:=
rgb(255,255,255)"><div dir=3D"ltr"><p style=3D"margin:0px"><span style=3D"f=
ont-family:arial,sans-serif"><span>=C2=A0</span>If they&#39;re<span>=C2=A0<=
/span></span><span style=3D"font-family:arial,sans-serif">parties intereste=
d in implementing more RBF policy options in Bitcoin Core, I think they&#39=
;re free to propose such<span>=C2=A0</span></span><span style=3D"font-famil=
y:arial,sans-serif">changes and invest the engineering effort to do so. If =
you&#39;re interested in advancing the state of<span>=C2=A0</span></span><s=
pan style=3D"font-family:arial,sans-serif">policy options in Bitcoin Core, =
there are a lot of interesting<span>=C2=A0</span></span>resources<span styl=
e=3D"font-family:arial,sans-serif"><span>=C2=A0</span>available and communi=
ties to<span>=C2=A0</span></span><span style=3D"font-family:arial,sans-seri=
f">encourage you in the learning process to contribute to the codebase [6].=
</span></p></div></blockquote><br></div><div style=3D"font-family:arial;fon=
t-size:14px;color:rgb(34,34,34)">Thanks for sharing the link. I would love =
to see 5 RBF policies available to use in bitcoin core. I have already trie=
d experimenting with a few on regtest and will try to open pull request if =
there are enough people interested to test it on other chains (testnet3, si=
gnet, mainnet)</div><div style=3D"font-family:arial;font-size:14px;color:rg=
b(34,34,34)"><br></div><div style=3D"font-family:arial;font-size:14px;color=
:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-size:14px;co=
lor:rgb(34,34,34)">[1]:=C2=A0<span><a rel=3D"noreferrer nofollow noopener" =
href=3D"https://docs.samourai.io/spend-tools" target=3D"_blank">https://doc=
s.samourai.io/spend-tools</a></span></div><div style=3D"font-family:arial;f=
ont-size:14px;color:rgb(34,34,34)"><span><br></span></div><div style=3D"fon=
t-family:arial;font-size:14px;color:rgb(34,34,34)"><span><br></span></div><=
div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)">/dev/fd0=
</div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><=
br></div><div style=3D"font-family:arial;font-size:14px"><br></div>
<div style=3D"font-family:arial;font-size:14px">
    <div>

            </div>

            <div>
        Sent with <a href=3D"https://proton.me/" rel=3D"noopener noreferrer=
" target=3D"_blank">Proton Mail</a> secure email.
    </div>
</div>
<div style=3D"font-family:arial;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Friday, June 17th, 2022 at 7:04 AM, Antoine Riard &lt;<a href=3D=
"mailto:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail.com<=
/a>&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr"><p style=3D"margin:0px;font-stretch:normal;lin=
e-height:normal;color:rgb(0,0,0)"><span style=3D"font-variant-ligatures:no-=
common-ligatures"><font face=3D"arial, sans-serif">Hi alicexbt,</font></spa=
n></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Thanks for taking time to review the pull request,</=
font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; 1)If something relies on a policy which can be =
changed without breaking consensus rules, how is it secure in any case with=
 or without full rbf?<span> </span></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Your Lightning node software relies on far more soft=
ware and hardware components than the transaction-relay p2p network. </font=
></span><span style=3D"font-family:arial,sans-serif">One could list the ope=
rating system on which is running your Lightning process or the compiler to=
olchain turning out </span><span style=3D"font-family:arial,sans-serif">you=
r Lightning source code in a binary artifact. Some weird kernel&#39;s memor=
y mapping change could allow access to </span><span style=3D"font-family:ar=
ial,sans-serif">your channel funding keys, _without_ breaking the Bitcoin c=
onsensus rules [0]. Moreover, your Lightning node is also </span><span styl=
e=3D"font-family:arial,sans-serif">relying on the existence of a global Int=
ernet allowing your HTLC transaction to flow from your physical host </span=
><span style=3D"font-family:arial,sans-serif">to the crowd of transactions =
confirming in the blockchain. Due to this &quot;protocol assumption&quot; y=
our channel balance </span><span style=3D"font-family:arial,sans-serif">wou=
ld be vulnerable to any change in your ISP routing policy, e.g refusing to =
accept your IPV4 traffic by a sudden </span><span style=3D"font-family:aria=
l,sans-serif">desiderata to impose an IPV6 supremacy. Still _without_ break=
ing the Bitcoin consensus rules. Of course, the odds of </span><span style=
=3D"font-family:arial,sans-serif">your ISP operator adopting this behavior =
are really low, mostly because your operator has to bind to social and </sp=
an><span style=3D"font-family:arial,sans-serif">economic constraints to sta=
y in business.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">And I believe this imperative to stay in business is=
 certainly not absent in the incentives of the Bitcoin node </font></span><=
span style=3D"font-family:arial,sans-serif">operators. You&#39;re free to r=
un any policy on your node, especially one hardening the safety of your ope=
rations</span><span style=3D"font-family:arial,sans-serif"> </span><span st=
yle=3D"font-family:arial,sans-serif">beyond the default one. However, if yo=
u start to a transaction-relay non-compatible with miner incentives, you </=
span><span style=3D"font-family:arial,sans-serif">won&#39;t have an efficie=
nt view of the blockspace demand, and from then won&#39;t be able to offer =
compelling feerates </span><span style=3D"font-family:arial,sans-serif">to =
execute your business transactions to satisfy your client needs. Or you won=
&#39;t consolidate your </span><span style=3D"font-family:arial,sans-serif"=
>wallet UTXOs at </span>times<span style=3D"font-family:arial,sans-serif"> =
of low-demand. Indeed, a sane visibility of the mempools might not be criti=
cal now for </span><span style=3D"font-family:arial,sans-serif">your Bitcoi=
n operations, but this is not likely to become true with miner&#39;s coinba=
se reward lowering with time </span><span style=3D"font-family:arial,sans-s=
erif">and the system security </span>relying<span style=3D"font-family:aria=
l,sans-serif"> on a fruitful fee market.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">So assuming there is a significant number of economi=
cally rational entities running p2p nodes, I think it&#39;s a </font></span=
><span style=3D"font-family:arial,sans-serif">reasonable assumption for Lig=
htning developers that a policy maximizing miner&#39;s income and economic =
nodes </span><span style=3D"font-family:arial,sans-serif">operations will b=
e widely run on the p2p network, and therefore lay its security model on th=
at. When there is a </span><span style=3D"font-family:arial,sans-serif">gap=
 between the economically optimal policy (full-rbf) and the effectively dep=
loyed one (optin), and this gap </span><span style=3D"font-family:arial,san=
s-serif">constitutes a flaw for exploitation, I believe it&#39;s better to =
fix it.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">If you have a different mode of thinking w.r.t how w=
e should design protocol in a trust-minimized, open, </font></span><span st=
yle=3D"font-family:arial,sans-serif">adversarial</span><span style=3D"font-=
family:arial,sans-serif"> </span><span style=3D"font-family:arial,sans-seri=
f">environment such as Bitcoin, I&#39;m curious to listen to it.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; If I write a python script that expects user to=
 enter char &#39;a&#39; or &#39;b&#39; but user can enter &#39;c&#39; and t=
here is no code to handle exceptions or other chars, will it be secure?</fo=
nt></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Of course not. If you deliver any critical software,=
 you should attach a solid manual explaining all the </font></span><span st=
yle=3D"font-family:arial,sans-serif">corner cases and rough edges. Even bet=
ter would be to enshrine the manual directly in your software API </span><s=
pan style=3D"font-family:arial,sans-serif">to minimize the footgunish behav=
iors. E.g, with any ECC library, forbidding to reuse nonces. If your </span=
>user<span style=3D"font-family:arial,sans-serif"> still ignores or misread=
 the manual and provides an insecure input, there is </span>not that<span s=
tyle=3D"font-family:arial,sans-serif"> much you can do.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">By analogy, I believe that&#39;s the same with Light=
ning. One recommendation of the deployment manual would </font></span><span=
 style=3D"font-family:arial,sans-serif">be to be always connected to a full=
-rbf transaction-relay topology. Defaulting to this rule and your node </sp=
an><span style=3D"font-family:arial,sans-serif">exposes far more surface of=
 attacks. Assuming the manual has been well-written (big assumption!), I do=
n&#39;t t</span><span style=3D"font-family:arial,sans-serif">hink the syste=
m designer would be to blame.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">That said, one issue to confess with current Lightni=
ng is our lack of understanding of what should be figured out in </font></s=
pan><span style=3D"font-family:arial,sans-serif">the LN user manual for saf=
e operations. I would say that&#39;s an active area of research [1] [2] [3]=
</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; 2)full-rbf is not default in the 2 open pull re=
quests, so this experiment still relies on users changing RBF policies manu=
ally. If majority of nodes use default opt-in policy, how would this affect=
 vulnerable projects?</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">If we define the goal as ensuring there is a signifi=
cant number of transaction-relay routes </font></span><span style=3D"font-f=
amily:arial,sans-serif">between the L2s nodes requiring full-rbf and the se=
t of miners supporting this policy, and </span><span style=3D"font-family:a=
rial,sans-serif">the set of miners is populated enough, there is no need to=
 convince the majority of nodes </span><span style=3D"font-family:arial,san=
s-serif">operators to switch to full-rbf.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Beyond landing the &#39;full-rbf&#39; pull request, =
in pursuit of a partial full-rbf deployment, </font></span><span style=3D"f=
ont-family:arial,sans-serif">I&#39;m thinking of reaching out to Lightning =
vendors to recommend running LN nodes operators</span><span style=3D"font-f=
amily:arial,sans-serif"> </span><span style=3D"font-family:arial,sans-serif=
">run their full-node with the setting enabled. And also to few mining pool=
 operators to </span><span style=3D"font-family:arial,sans-serif">advocate =
the potential increase in their income.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Given there are like 17000 public LN nodes, if half =
of them adopt full-rbf it should give </font></span><span style=3D"font-fam=
ily:arial,sans-serif">already a good number of full-rbf transaction-relay r=
outes across the p2p network graph. </span><span style=3D"font-family:arial=
,sans-serif">When we&#39;re there, we can measure and think more about how =
to tune the full-rbf sub-topology.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; 2-3% transactions are replaced with opt-in RBF,=
 if someone did not replace earlier why would they do it with full RBF?</fo=
nt></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Because it&#39;s breaking the reliability and securi=
ty of their use-cases. Use-cases which didn&#39;t exist </font></span><span=
 style=3D"font-family:arial,sans-serif">a few years ago. The mempool DoS ve=
ctor is described here [4]. To the best of my understanding, it might </spa=
n><span style=3D"font-family:arial,sans-serif">affect a bunch of use-cases,=
 such as dual-funded channels, on-chain DLCs, p2p </span>coinjoins<span sty=
le=3D"font-family:arial,sans-serif">, batched submarine </span><span style=
=3D"font-family:arial,sans-serif">swaps out. With the attack described, the=
 honest set of users might not have visibility of the network </span><span =
style=3D"font-family:arial,sans-serif">mempools that there is a malicious, =
low-cost, opt-out double-spend preventing the propagation of their multi-pa=
rty </span><span style=3D"font-family:arial,sans-serif">transaction. With t=
he existence of a full-rbf transaction-relay topology, the multi-party tran=
saction </span><span style=3D"font-family:arial,sans-serif">is able to repl=
ace the </span>optout<span style=3D"font-family:arial,sans-serif">.</span><=
/p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">None of those use-cases were deployed a few years ag=
o, and the understanding of the interactions with the </font></span><span s=
tyle=3D"font-family:arial,sans-serif">mempool policy is still nascent among=
 their operators. However, if we assume that layering is a way to grow </sp=
an><span style=3D"font-family:arial,sans-serif">the Bitcoin ecosystem, as I=
 do, it is reasonable to expect they will constitute a notable share of the=
 </span><span style=3D"font-family:arial,sans-serif">Bitcoin transaction tr=
affic during the next decade.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; I am not opposed to full-rbf; rather, I am oppo=
sed to the notion that full-rbf will solve all problems</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">I wished we had a magic Silver Bullet (tm) solving a=
ll the Bitcoin problems...</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">I&#39;m only advocating a partial full-rbf deploymen=
t to solve a real precise security issue affecting </font></span><span styl=
e=3D"font-family:arial,sans-serif">multi-party funded transactions. That sa=
id, full-rbf is far from solving the known set of problems </span><span sty=
le=3D"font-family:arial,sans-serif">affecting the L2s due to interactions w=
ith network mempools. E,g, see package relay motivation [5]</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; I would suggest users to try Bitcoin Knots inst=
ead which already has an option to disable all RBF policies if required, op=
t-in and full RBF policy.</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Selecting a full-node to underpin any serious Bitcoi=
n infrastructure or secure a significant stack of coins </font></span><span=
 style=3D"font-family:arial,sans-serif">should be submitted to a fully-fled=
ged decision-making process. Many factors are likely to </span>matter<span =
style=3D"font-family:arial,sans-serif"> such as </span><span style=3D"font-=
family:arial,sans-serif">the level of activity of the contributor community=
, the chain of trust w.r.t dependencies, the security incident t</span><spa=
n style=3D"font-family:arial,sans-serif">rack records, the quality of the d=
ocumentation, the exhaustivity and robustness of the set of features, ...</=
span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">This process might take tens of hours, to be duplica=
ted by the number of node operators who would have to </font></span><span s=
tyle=3D"font-family:arial,sans-serif">do the full-node vending switch. If y=
ou consider the cognitive cost at the level of the Bitcoin </span><span sty=
le=3D"font-family:arial,sans-serif">ecosystem, it&#39;s far less costly to =
implement and </span>review a few<span style=3D"font-family:arial,sans-seri=
f"> lines of codes in Bitcoin Core.</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">&gt; Developers should provide basic RBF policy opti=
ons rather than attempting to define what constitutes a good policy and rem=
oving the ability to disable something when necessary.</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Of course, this statement assumes there is a clear l=
ine between the developers and the users. Developers </font></span><span st=
yle=3D"font-family:arial,sans-serif">are also Bitcoin users, and they&#39;r=
e modifying the software to suit their use-case needs. And that&#39;s exact=
ly </span><span style=3D"font-family:arial,sans-serif">the purpose of the &=
#39;full-rbf&#39; PR I&#39;m proposing, aiming to propose a &quot;good&quot=
; policy for a Lightning node, without actually seeking to change the defau=
lt. If they&#39;re </span><span style=3D"font-family:arial,sans-serif">part=
ies interested in implementing more RBF policy options in Bitcoin Core, I t=
hink they&#39;re free to propose such </span><span style=3D"font-family:ari=
al,sans-serif">changes and invest the engineering effort to do so. If you&#=
39;re interested in advancing the state of </span><span style=3D"font-famil=
y:arial,sans-serif">policy options in Bitcoin Core, there are a lot of inte=
resting </span>resources<span style=3D"font-family:arial,sans-serif"> avail=
able and communities to </span><span style=3D"font-family:arial,sans-serif"=
>encourage you in the learning process to contribute to the codebase [6].</=
span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><br></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">Antoine</font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0);min-height:13px"><font face=3D"arial, sans-serif"><span style=3D"font-v=
ariant-ligatures:no-common-ligatures"></span><br></font></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[0] <a href=3D"https://dirtycow.ninja" rel=3D"norefe=
rrer nofollow noopener" target=3D"_blank">https://dirtycow.ninja</a></font>=
</span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[1] <a href=3D"https://github.com/t-bast/lightning-d=
ocs/blob/master/pinning-attacks.md" rel=3D"noreferrer nofollow noopener" ta=
rget=3D"_blank">https://github.com/t-bast/lightning-docs/blob/master/pinnin=
g-attacks.md</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[2] <a href=3D"https://arxiv.org/pdf/2006.01418.pdf"=
 rel=3D"noreferrer nofollow noopener" target=3D"_blank">https://arxiv.org/p=
df/2006.01418.pdf</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[3] <a href=3D"https://arxiv.org/pdf/2006.08513.pdf"=
 rel=3D"noreferrer nofollow noopener" target=3D"_blank">https://arxiv.org/p=
df/2006.08513.pdf</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[4] <a href=3D"https://lists.linuxfoundation.org/pip=
ermail/lightning-dev/2021-May/003033.html" rel=3D"noreferrer nofollow noope=
ner" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightnin=
g-dev/2021-May/003033.html</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[5] <a href=3D"https://lists.linuxfoundation.org/pip=
ermail/bitcoin-dev/2022-May/020493.html" rel=3D"noreferrer nofollow noopene=
r" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2022-May/020493.html</a></font></span></p>
<p style=3D"margin:0px;font-stretch:normal;line-height:normal;color:rgb(0,0=
,0)"><span style=3D"font-variant-ligatures:no-common-ligatures"><font face=
=3D"arial, sans-serif">[6] <a href=3D"https://www.summerofbitcoin.org" rel=
=3D"noreferrer nofollow noopener" target=3D"_blank">https://www.summerofbit=
coin.org</a></font></span></p>
<br></div><br><div class=3D"gmail_quote"><div class=3D"gmail_attr" dir=3D"l=
tr">Le jeu. 16 juin 2022 =C3=A0 00:15, alicexbt &lt;<a href=3D"mailto:alice=
xbt@protonmail.com" rel=3D"noreferrer nofollow noopener" target=3D"_blank">=
alicexbt@protonmail.com</a>&gt; a =C3=A9crit :<br></div><blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex" class=3D"gmail_quote"><div style=3D"font-family:arial;font-size:=
14px;color:rgb(34,34,34)">Hi Antoine,</div><div style=3D"font-family:arial;=
font-size:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:ari=
al;font-size:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:=
arial;font-size:14px;color:rgb(34,34,34)">Thanks for opening the pull reque=
st to add support for full-rbf in Bitcoin Core. I have a disagreements with=
 the approach and questions.</div><div style=3D"font-family:arial;font-size=
:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-s=
ize:14px;color:rgb(34,34,34)"><blockquote style=3D"padding:0px 0px 0px 1rem=
;margin:0px;border-left:4px solid rgb(229,229,229);color:rgb(0,0,0);font-fa=
mily:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-serif;background-color=
:rgb(255,255,255)" type=3D"cite"><span dir=3D"ltr">Recent discussions among=
 LN devs have brought back on the surface concerns about the security of mu=
lti-party funded transactions (coinjoins, dual-funded LN channels, on-chain=
 DLCs, ...). It turns out there is a low-fruit, naive DoS vector playable a=
gainst the funding flow of any such construction due to the lack of existen=
t full-rbf transaction-relay topology on today&#39;s p2p network [0] [1].<s=
pan> </span></span></blockquote><br></div><div style=3D"font-family:arial;f=
ont-size:14px;color:rgb(34,34,34)">1)If something relies on a policy which =
can be changed without breaking consensus rules, how is it secure in any ca=
se with or without full rbf? If I write a python script that expects user t=
o enter char &#39;a&#39; or &#39;b&#39; but user can enter &#39;c&#39; and =
there is no code to handle exceptions or other chars, will it be secure?  <=
/div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><b=
r></div><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"=
>2)full-rbf is not default in the 2 open pull requests, so this experiment =
still relies on users changing RBF policies manually. If majority of nodes =
use default opt-in policy, how would this affect vulnerable projects?</div>=
<div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><br></d=
iv><div style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><blo=
ckquote style=3D"padding:0px 0px 0px 1rem;margin:0px;border-left:4px solid =
rgb(229,229,229);color:rgb(0,0,0);font-family:Arial,&quot;Helvetica Neue&qu=
ot;,Helvetica,sans-serif;background-color:rgb(255,255,255)" type=3D"cite"><=
span dir=3D"ltr">If you&#39;re a mining operator looking to increase your i=
ncome, you might be interested to experiment with full-rbf as a policy.</sp=
an></blockquote><br></div><div style=3D"font-family:arial;font-size:14px;co=
lor:rgb(34,34,34)">Miners can only increase their income if users replace t=
ransactions. 2-3% transactions are replaced with opt-in RBF, if someone did=
 not replace earlier why would they do it now even with full RBF? Or even i=
f we add some users in it who could not signal for some reasons, do you thi=
nk it would be anything above 5%?</div><div style=3D"font-family:arial;font=
-size:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;f=
ont-size:14px;color:rgb(34,34,34)"><blockquote style=3D"padding:0px 0px 0px=
 1rem;margin:0px;border-left:4px solid rgb(229,229,229);color:rgb(0,0,0);fo=
nt-family:Arial,&quot;Helvetica Neue&quot;,Helvetica,sans-serif;background-=
color:rgb(255,255,255)" type=3D"cite"><span dir=3D"ltr">If you&#39;re a Bit=
coin user or business and you don&#39;t like full-rbf, please express an op=
inion on how it might affect your software/operations. I&#39;m always inter=
ested to learn more about mempool and transaction-relay interactions with u=
pper-layers and applications and to listen to feedback in those areas, and =
I guess a lot of other Bitcoin researchers/devs too. I know there have been=
 a lot of concerns about full-rbf in the past, however I believe the Bitcoi=
n ecosystem has matured a lot since then.</span></blockquote><br></div><div=
 style=3D"font-family:arial;font-size:14px;color:rgb(34,34,34)"><span>I am =
not opposed to full-rbf; rather, I am opposed to the notion that full-rbf w=
ill solve all problems and the lack of basic options in Bitcoin Core to emp=
loy/disable different RBF policies. There is also a speculation about makin=
g full RBF default in an year which isn&#39;t relevant to discuss at this p=
oint without trying different RBF policies.</span></div><div style=3D"font-=
family:arial;font-size:14px;color:rgb(34,34,34)"><br></div><div style=3D"fo=
nt-family:arial;font-size:14px;color:rgb(34,34,34)">I would suggest users t=
o try Bitcoin Knots instead which already has an option to disable all RBF =
policies if required, opt-in and full RBF policy. This can also be done usi=
ng GUI if not familiar with config option <code>mempoolreplacement</code>=
=E2=80=8B.</div><div style=3D"font-family:arial;font-size:14px;color:rgb(34=
,34,34)"><br></div><div style=3D"font-family:arial;font-size:14px;color:rgb=
(34,34,34)"><span>The rationale in PR #16171 was insufficient to justify re=
moving it in the first place, had 2 NACKs and was reopened to merge it. Why=
 bother with a few lines of code that may allow someone disable it if requi=
red in local mempool since it&#39;s only useful when a big percentage of mi=
ners utilize it and essentially underused according to the PR author? Devel=
opers should provide basic RBF policy options rather than attempting to def=
ine what constitutes a good policy and removing the ability to disable some=
thing when necessary.</span></div><div style=3D"font-family:arial;font-size=
:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;font-s=
ize:14px;color:rgb(34,34,34)"><br></div><div style=3D"font-family:arial;fon=
t-size:14px;color:rgb(34,34,34)">/dev/fd0</div><div style=3D"font-family:ar=
ial;font-size:14px"><br></div>
<div style=3D"font-family:arial;font-size:14px">
    <div>

            </div>

            <div>
        Sent with <a rel=3D"noreferrer nofollow noopener" href=3D"https://p=
roton.me/" target=3D"_blank">Proton Mail</a> secure email.
    </div>
</div>
<div style=3D"font-family:arial;font-size:14px"><br></div><div>
        ------- Original Message -------<br>
        On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"nore=
ferrer nofollow noopener" target=3D"_blank">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br><br>
        <blockquote type=3D"cite">
            <div dir=3D"ltr">Hi list,<br><br>Recent discussions among LN de=
vs have brought back on the surface concerns about the security of multi-pa=
rty 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 construction due to the lack of existent full=
-rbf transaction-relay topology on today&#39;s p2p network [0] [1]. While i=
t does not consist in a direct loss of funds, if exploited well I think it&=
#39;s annoying enough to inflict significant timevalue loss or fee-bumping =
waste <br>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].<br><br>For that reason, I believe it would be benefic=
ial to the flourishing of multi-party funded transactions to fix the Dos ve=
ctor by seeing a subset of the network running full-rbf and enabling propag=
ation of honest multi-party transactions to the interested miners, replacin=
g potential non-signaling double-spend from a malicious counterparty. Movin=
g towards that direction, I&#39;ve submitted a small patch against Bitcoin =
Core enabling it to turn on full-rbf as a policy, still under review [3]. T=
he default setting stays **false**, i.e keeping opt-in RBF as a default rep=
lacement policy. I&#39;ve started to run the patch on a public node at 146.=
190.224.15.<br><br>If you&#39;re a node operator curious to play with full-=
rbf, feel free to connect to this node or spawn up a toy, public node yours=
elf. There is a ##uafrbf libera chat if you would like information on the s=
ettings or looking for full-rbf friends (though that step could be automate=
d in the future by setting up a dedicated network bit and reserving a few o=
utbound slots for them).<br><br>If you&#39;re a mining operator looking to =
increase your income, you might be interested to experiment with full-rbf a=
s a policy. Indeed, in the future I believe the multi-party transactions is=
suers who need full-rbf to secure their funding flow should connect by defa=
ult to full-rbf peers. One can conjecture that their transactions are likel=
y to be more compelling in their feerate as their liquidity needs are highe=
r than the simple transaction. For today, I think we have really few standa=
rds and bitcoin softwares relying on multi-party funded transactions [4].<b=
r><br>If you&#39;re a Bitcoin user or business and you don&#39;t like full-=
rbf, please express an opinion on how it might affect your software/operati=
ons. I&#39;m always interested to learn more about mempool and transaction-=
relay interactions with upper-layers and applications and to listen to feed=
back in those areas, and I guess a lot of other Bitcoin researchers/devs to=
o. I know there have been a lot of concerns about full-rbf in the past, how=
ever I believe the Bitcoin ecosystem has matured a lot since then.<br><br>A=
ny mistakes or missing context is my own.<br><br>Cheers,<br>Antoine<br><br>=
[0] For more info about replace-by-fee, see <a rel=3D"noreferrer nofollow n=
oopener" href=3D"https://bitcoinops.org/en/topics/replace-by-fee/" target=
=3D"_blank">https://bitcoinops.org/en/topics/replace-by-fee/</a><br><br>[1]=
 For more details about the DoS vector, see <a rel=3D"noreferrer nofollow n=
oopener" href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/=
2021-May/003033.html" target=3D"_blank">https://lists.linuxfoundation.org/p=
ipermail/lightning-dev/2021-May/003033.html</a><br><br>[2] E.g I think it d=
oes not affect the Lightning Pool service, as there is a preliminary step w=
here the participant funds are locked first in a 2-of-2 with the coordinato=
r before being committed in the multi-party batch transaction.<br><br>[3] <=
a rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/bitcoin/b=
itcoin/pull/25353" target=3D"_blank">https://github.com/bitcoin/bitcoin/pul=
l/25353</a><br><br>[4] E.g DLCs : <a rel=3D"noreferrer nofollow noopener" h=
ref=3D"https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transac=
tions.md" target=3D"_blank">https://github.com/discreetlogcontracts/dlcspec=
s/blob/master/Transactions.md</a> ; Lightning dual-funded channel : <a rel=
=3D"noreferrer nofollow noopener" href=3D"https://github.com/lightning/bolt=
s/pull/851" target=3D"_blank">https://github.com/lightning/bolts/pull/851</=
a><br></div>

        </blockquote><br>
    </div></blockquote></div>

        </blockquote><br>
    </div></blockquote></div>

--000000000000f4550a05e1fdc99a--