Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 05AD8C002D for ; Thu, 16 Jun 2022 01:02:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id CFC1F83E74 for ; Thu, 16 Jun 2022 01:02:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYvW1H6nPhV7 for ; Thu, 16 Jun 2022 01:02:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by smtp1.osuosl.org (Postfix) with ESMTPS id 042A083E44 for ; Thu, 16 Jun 2022 01:02:52 +0000 (UTC) Received: by mail-yb1-xb2a.google.com with SMTP id u99so23391569ybi.11 for ; Wed, 15 Jun 2022 18:02:52 -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=wIQxuWJ8xYDvLF5MXhErQ2jBJh/SRfWteinOj2glRYM=; b=i1cshPT8GhgVWdrssmK8+DGwcFkJaZOMhYkOi0VJrG1BvYidK3nkoYoavLwk4p/Qz0 JXcrDq8efHNgCmqD8HCOMbkqUcOATViSBs1wLc7PUzCQngB6+RAIL/O2Kq8EQZjSfekz godg+9RMdvRGpe6vqn/D1alUjK6TB1aRYLg1MSksRVwC05gXWie8zeTnheT6bY5lQP+c lnfDixDlc75M5/q01bNx+kqxcHNORbybUVkTNpPaDpSd7mMyu7ejguihkqRUiHbpkQRQ vugHHWxxEZPV8Cl67vOapsi7u7hfgjsVs+xqT5jTxTSvowNAntqBxnPyxygJ+6i6cd8D lv1w== 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=wIQxuWJ8xYDvLF5MXhErQ2jBJh/SRfWteinOj2glRYM=; b=tMDCZbjfhjz6zmlcwAj/Ilev9EOpy9yROjvEFHZ4XD9AKnwEKBV99McJdyxXLRgydh LrFKHmxXKTwMeZbsO8l4V12nS5faqw7DDwF8GbsZOhPSrOLgisv5qxHdGJKE1EO0mLX9 Tec/mLrtKlGg2a0qchny8g66hXVSINrKPteYNs6iamaXFDF2ABt5RhvQbuiwduNkEpCt HqQRtDYZW3KGjJ8MQVRGHCZ0Icho+V/lR5B1I0W6OyMKmxTGJbLgRxpPMOvK/+fViak7 KIkRsdmUAfQtJD8t9lHwGtM3XBtk+fQkg/gLTJ067vJ4YpeqsbjApdN3NCkfIBP1Cwun jblw== X-Gm-Message-State: AJIora9QHoHBxEz7+FjUZsUh+43iRJ+c6NaIsAk9vPqY3YnLpHyRofey c2lQa1rCH7Or1wuRE680IUA3jGZKaCoznXHted4= X-Google-Smtp-Source: AGRyM1uRAVN14yvMEZ5qcjEkb8NEZzYFMiuiSpNADhU+3kI3C+ijT8T3vwwp5bziK3itx5Ilp2BThKD5ewAKZiFLwSw= X-Received: by 2002:a25:cbc3:0:b0:664:89fb:542b with SMTP id b186-20020a25cbc3000000b0066489fb542bmr2957460ybg.23.1655341370615; Wed, 15 Jun 2022 18:02:50 -0700 (PDT) MIME-Version: 1.0 References: <7aP7ve-x6uMLSY2a9ZvpkyEc7uOdWmCGOs-S2ly1klRKzm5kVT4zjC9i0V6k1R0Cr9Xloq6Z4zmZ0LfquOxFtyhrA0RgsfG4qq760T4dfZM=@protonmail.com> In-Reply-To: <7aP7ve-x6uMLSY2a9ZvpkyEc7uOdWmCGOs-S2ly1klRKzm5kVT4zjC9i0V6k1R0Cr9Xloq6Z4zmZ0LfquOxFtyhrA0RgsfG4qq760T4dfZM=@protonmail.com> From: Greg Sanders Date: Wed, 15 Jun 2022 21:02:39 -0400 Message-ID: To: alicexbt , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000060a9cf05e186324c" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2022 01:02:55 -0000 --00000000000060a9cf05e186324c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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? The security of LN and other related systems are something like: "given proper fees offered, can a transaction be mined within N blocks?" You're simply not allowed to out-bid your attacker in certain circumstances due to today's miner incentive-incompatible relay policies. There is also a time-value dimension to this with other simpler systems where your funds can be locked up for potentially weeks for similar reasons= . > ... arguments about how many people RBF being sufficient or not ... The idea that we should only build robust systems after the broken ones are attacked is not a serious argument. > I am not opposed to full-rbf; rather, I am opposed to the notion that full-rbf will solve all problems This is a strawman. Full-RBF is a simple, obvious, incentive-compatible step to getting closer to more robust layer two systems. Fixing the rest of the holes is for future proposals which are a bit more involved and definitely less mature. > would suggest users to try Bitcoin Knots instead > 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. If Knots has these knobs, just use Knots rather than lobby all implementations to have miner incentive incompatible knobs? Cheers, Greg On Wed, Jun 15, 2022 at 8:27 PM alicexbt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Antoine, > > > Thanks for opening the pull request to add support for full-rbf in Bitcoi= n > Core. I have a few disagreements with the approach and questions. > > Recent discussions among LN devs have brought back on the surface concern= s > about the security of multi-party funded transactions (coinjoins, > dual-funded LN channels, on-chain DLCs, ...). It turns out there is a > low-fruit, naive DoS vector playable against the funding flow of any such > 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? I= f > I write a python script that expects user to enter char 'a' or 'b' but us= er > 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 experiment > still relies on users changing RBF policies manually. If majority of node= s > use default opt-in policy, how would this affect vulnerable projects? > > If you're a mining operator looking to increase your income, you might be > interested to experiment with full-rbf as a policy. > > > Miners can only increase their income if users replace transactions. 2-3% > transactions are replaced with opt-in RBF, if someone did not replace > earlier why would they do it with full RBF? Or even if we add some users = in > it who could not signal for some reasons, do you think it would be anythi= ng > 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 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, howeve= r > 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 Bitcoin > Core to employ/disable different RBF policies. There is also a speculatio= n > about making full RBF default in an year which isn't relevant to discuss = at > this point without trying different RBF policies. > > I would suggest users to try Bitcoin Knots instead which already has an > option to disable all RBF policies if required, opt-in and full RBF polic= y. > 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 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 required in local > mempool since it's only useful when a big percentage of miners utilize it > 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 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 concern= s > about the security of multi-party funded transactions (coinjoins, > dual-funded LN channels, on-chain DLCs, ...). It turns out there is a > low-fruit, naive DoS vector playable against the funding flow of any such > 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 lo= ss > 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-par= ty > transactions to the interested miners, replacing potential non-signaling > double-spend from a malicious counterparty. Moving towards that direction= , > 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 outbound > slots for them). > > If you're a mining operator looking to increase your income, you might be > interested to experiment with full-rbf as a policy. Indeed, in the future= I > believe the multi-party transactions issuers who need full-rbf to secure > their funding flow should connect by default to full-rbf peers. One can > conjecture that their transactions are likely to be more compelling in > their feerate as their liquidity needs are higher than the simple > 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 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, howeve= r > 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/003033= .html > > [2] E.g I think it does not affect the Lightning Pool service, as there i= s > 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 batch > transaction. > > [3] https://github.com/bitcoin/bitcoin/pull/25353 > > [4] E.g DLCs : > https://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions= .md > ; Lightning dual-funded channel : > https://github.com/lightning/bolts/pull/851 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000060a9cf05e186324c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0If something relies on a policy which can be changed without breaking cons= ensus rules, how is it secure in any case with or without full rbf?<= div>
= The security of LN and oth= er related systems are something like: "given proper fees offered, can= a transaction be mined within N blocks?" You're simply not allowe= d=C2=A0to out-bid your attacker in certain circumstances due to today's= miner incentive-incompatible=C2=A0relay policies.

There is also a time-value dimens= ion to this with other simpler systems where your funds can be locked up fo= r potentially weeks for similar reasons.

>=C2=A0 ... arguments about how many peopl= e RBF being sufficient or not ...

The idea that we should only build robust systems a= fter the broken ones are attacked is not a serious argument.<= /div>

>=C2= =A0I am not = opposed to full-rbf; rather, I am opposed to the notion that full-rbf will = solve all problems

This is a strawman.

Full-RBF is a simple, obvious, incentive-compatible step to ge= tting closer to more robust layer two systems.=C2=A0Fixing the rest of the holes is for future= proposals which are a bit more involved and definitely less mature.=

>=C2=A0=C2=A0wou= ld suggest users to try Bitcoin Knots instead
>=C2=A0Developers should provide ba= sic RBF policy options rather than attempting to define what constitutes a = good policy and removing the ability to disable something when necessary.

If Knots has these knobs, just use Knots rat= her than lobby all implementations to have miner incentive incompatible kno= bs?

Cheers,
Greg

On Wed, Jun 15, 20= 22 at 8:27 PM alicexbt via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrot= e:
Hi A= ntoine,


Thanks for = opening the pull request to add support for full-rbf in Bitcoin Core. I hav= e a few 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 transacti= ons (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-rel= ay topology on today's p2p network [0] [1].=C2=A0
1)If something reli= es on a policy which can be changed without breaking consensus rules, how i= s it secure in any case with or without full rbf? If I write a python scrip= t that expects user to enter char 'a' or 'b' but user can e= nter 'c' and there is no code to handle exceptions or other chars, = will it be secure?=C2=A0=C2=A0

=
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 woul= d this affect vulnerable projects?
=
If you're a mining operator looking to increase your income, you m= ight be interested to experiment with full-rbf as a policy.
Miners can only increase t= heir income if users replace transactions. 2-3% transactions are replaced w= ith opt-in RBF, if someone did not replace earlier why would they do it wit= h full RBF? Or even if we add some users in it who could not signal for som= e reasons, do you think it would be anything above 5%?

If you're a Bitcoin user or business and you d= on't like full-rbf, please express an opinion on how it might affect yo= ur software/operations. I'm always interested to learn more about mempo= ol and transaction-relay interactions with upper-layers and applications an= d 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-r= bf in the past, however I believe the Bitcoin ecosystem has matured a lot s= ince 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 Bitcoin = Core to employ/disable different RBF policies. There is also a speculation = about making full RBF default in an year which isn't relevant to discus= s at this point without trying different RBF policies.

I w= ould suggest users to 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 using GUI if not familiar with config option=C2=A0mempoolreplace= ment=E2=80=8B.

The rationale in PR #16171 was insuff= icient to justify removing it in the first place, had 2 NACKs and was reope= ned 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 it and essentially underused according to = the PR author? Developers should provide basic RBF policy options rather th= an attempting to define what constitutes a good policy and removing the abi= lity to disable something when necessary.


/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, June 14th, 2022 at 5:55 AM, Antoine Riard via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Hi list,

Recent discussions among LN 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'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
to the future providers or distributed swarm of users doing multi= -party funded transactions. Of course, it can be fixed one layer above by i= ntroducing either fidelity bonds or a reliable centralized coordinator, tho= ugh at the price of an overhead per-participant ressources cost and loss in= system openness [1].

For that reason, I believe it would be 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'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'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 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).

If you'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].
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/operati= ons. I'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.

A= ny 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/p= ipermail/lightning-dev/2021-May/003033.html

[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.

[3] <= a href=3D"https://github.com/bitcoin/bitcoin/pull/25353" rel=3D"noreferrer = nofollow noopener" target=3D"_blank">https://github.com/bitcoin/bitcoin/pul= l/25353

[4] E.g DLCs : https://github.com/discreetlogcontracts/dlcspec= s/blob/master/Transactions.md ; Lightning dual-funded channel : https://github.com/lightning/bolts/pull/851

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000060a9cf05e186324c--