path: root/87/242ef0f7e8f4b3cd7789ec23daeb0bd1e9ab1d

Return-Path: <bastien.teinturier@acinq.fr>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 791C4C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 09:30:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 6088940996
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 09:30:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=acinq-fr.20210112.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2E0VH61rYme6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 09:30:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com
 [IPv6:2607:f8b0:4864:20::b2c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C94E140959
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Feb 2022 09:30:24 +0000 (UTC)
Received: by mail-yb1-xb2c.google.com with SMTP id 23so48894439ybf.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 01 Feb 2022 01:30:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=acinq-fr.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=PgK7Uw/bwir4uEMXUcAA2nXlDqWKUXZ2j0d0YyoLdq0=;
 b=qGmA9qlQuLgPEt0btwUu91RNUsmqAaDIGb4cZ7/DlgL8Mq60xkdOmJtRQu2a7m7fJe
 MN+f/vCy2n7vbyUCczZaNUht8cPKdCRxBww8ktPY8o6PVDsr0ZPFJm5qU0K8fOwXrX0n
 ioHRZLnxnBxLjd1/g5W768yO5h4pkA+e2oRS0tzIObDh0zDbJCTbXFJlG9uBW4yq9bxq
 1mxb9/32iuSQvF3HcwDWjab5V7N8uoQ1LTaRrC4qEpmTWRvypbMECb/j4I3gQ6HKOJ3z
 a6VTYaPGhcPGAGYZe0mPkmzxAsNe5oJmVate/N9T8M6AVbyPSsHbIYD7JckMeqBK8FaI
 DCbA==
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=PgK7Uw/bwir4uEMXUcAA2nXlDqWKUXZ2j0d0YyoLdq0=;
 b=c7zYEYD4uA1TyRopSc1ofqZpSzhBlkb+cfanXQnHsBY3airpWvmEUPHUydwb2AR0JJ
 cxbFzusb5ALE7CUhY507R6VyTkNuie5R+0012D8Sg6KwHA1m0s2qhKSAQTpzmGcp6AZG
 aZAGlx+Wl/g/6Diyvnm089OXwCDImOZE3ND7ZRG9CLk3U9QIblgetKVFKnk8QVkO86K2
 OUuDeNv6FO/6THZULmhq6BSDoGSCp5X6sBB2mCCjKUEiJClvv+WAlR0IYARD/2f/FNMA
 dUS4hb7Z7qnPIavYDFgI/lNvr0SK6UuQLUW8Fuh7mu1Pxr66LIKrzQ3Uh6pQ83tLLHw4
 zDgg==
X-Gm-Message-State: AOAM533U/JQ/PsGXQu97Yv/x+eRotGDYZvFl4K1WezYIifejS9chc7zq
 cysaArSd/WNCk+/HgpGmR2E5ui9eLCPCzBJfHtb86w==
X-Google-Smtp-Source: ABdhPJzdC8X7oro+W7utoEtAG+7PP2MXEFKPizIPttONEdOfnTtKDEQ7XtQ7G28xOKU4P6xaZkdr10QBNKYdlpPpvaU=
X-Received: by 2002:a05:6902:100a:: with SMTP id
 w10mr36651411ybt.668.1643707823670; 
 Tue, 01 Feb 2022 01:30:23 -0800 (PST)
MIME-Version: 1.0
References: <MunATIf--3-2@tutanota.de>
In-Reply-To: <MunATIf--3-2@tutanota.de>
From: Bastien TEINTURIER <bastien@acinq.fr>
Date: Tue, 1 Feb 2022 10:30:12 +0100
Message-ID: <CACdvm3O4sQ_kF+y9R73c1wiDiTos9Zs7jJQZEQrc8Uz5SsSx1g@mail.gmail.com>
To: Prayank <prayank@tutanota.de>, Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="000000000000f1dd0405d6f18cc5"
X-Mailman-Approved-At: Tue, 01 Feb 2022 09:35:59 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving RBF Policy
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, 01 Feb 2022 09:30:26 -0000

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

Hi AJ, Prayank,

> I think that's backwards: we're trying to discourage people from wasting
> the network's bandwidth, which they would do by publishing transactions
> that will never get confirmed -- if they were to eventually get confirmed
> it wouldn't be a waste of bandwith, after all. But if the original
> descendent txs were that sort of spam, then they may well not be
> submitted again if the ancestor tx reaches a fee rate that's actually
> likely to confirm.

But do you agree that descendants only matter for DoS resistance then,
not for miner incentives?

I'm asking this because I think a new set of policies should separate
policies that address the miner incentives from policies that address
the DoS issues.

The two policies I proposed address miner incentives. I think they're
insufficient to address DoS issues. But adding a 3rd policy to address
DoS issues may be a good solution?

I think that rate-limiting p2p as you suggest (and Gloria also mentioned
it) is likely a better way of fixing the DoS concerns than a descendant
rule like BIP 125 rule 5 (which as I mentioned earlier, is problematic
because the descendent set varies from one mempool to another).

I would like to add a small update to my policy suggestions. The X and Y
percentage increase should be met for both the ancestor scores AND the
transaction in isolation. Otherwise I could replace txA with txA' that
uses a new ancestor txB that has a high fee and high feerate, while txA'
has a low fee and low feerate. It's then possible for txB to confirm
without txA', and what would remain then in the mempool would be worse
than before the replacement.

> All you need is for there to be *a* path that follows the new relay rules
> and gets from your node/wallet to perhaps 10% of hashpower, which seems
> like something wallet providers could construct relatively quickly?

That's true, maybe we can be more optimistic about the timeline for
using an updated set of policies ;)

> Do you think such multi party contracts are vulnerable by design
> considering they rely on policy that cannot be enforced?

It's a good question. Even though these policies cannot be enforced, if
they are rational to apply by nodes, I think it's ok to rely on them.
Others may disagree with that, but I guess it's worth a separate thread.

> Not sure I understand this part because if a transaction is on-chain
> it can't be replaced.

Sorry, that was a bit unclear.

Suppose I have txA that I want to RBF, but I only have unconfirmed utxos
and I can't simply lower its existing outputs to reach my desired
feerate.

I must make one of my unconfirmed utxos confirm asap just to be able to
use it to RBF txA. That means I'll need to pay fees a first time just to
convert one of my unconfirmed utxos to a confirmed one. Then I'll pay
the fees to bump txA. I had to overpay fees compared to just using my
unconfirmed utxo in the first place (and manage more complexity to track
the confirmation of my unconfirmed utxo).

Thanks for your feedback!
Bastien

Le mar. 1 f=C3=A9vr. 2022 =C3=A0 03:47, Prayank <prayank@tutanota.de> a =C3=
=A9crit :

> Hi Bastein,
>
> > This work will highly improve the security of any multi-party contract
> trying to build on top of bitcoin
>
> Do you think such multi party contracts are vulnerable by design
> considering they rely on policy that cannot be enforced?
>
> > For starters, let me quickly explain why the current rules are hard to
> work with in the context of lightning
>
> Using the term 'rules' can be confusing sometimes because it's just a
> policy and different from consensus rules. I wish we could change this in
> the BIP with something else.
>
> > I'm actually paying a high fee twice instead of once (and needlessly
> using on-chain space, our scarcest asset, because we could have avoided
> that additional transaction
>
> Not sure I understand this part because if a transaction is on-chain it
> can't be replaced.
>
> > The second biggest pain point is rule 3. It prevents me from efficientl=
y
> using my capital while it's unconfirmed
>
> > I'm curious to hear other people's thoughts on that. If it makes sense,
> I would propose the following very simple rules
>
> Looks interesting however not sure about X and Y.
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>

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

<div dir=3D"ltr">Hi AJ, Prayank,<br><br>&gt; I think that&#39;s backwards: =
we&#39;re trying to discourage people from wasting<br>&gt; the network&#39;=
s bandwidth, which they would do by publishing transactions<br>&gt; that wi=
ll never get confirmed -- if they were to eventually get confirmed<br>&gt; =
it wouldn&#39;t be a waste of bandwith, after all. But if the original<br>&=
gt; descendent txs were that sort of spam, then they may well not be<br>&gt=
; submitted again if the ancestor tx reaches a fee rate that&#39;s actually=
<br>&gt; likely to confirm.<br><br>But do you agree that descendants only m=
atter for DoS resistance then,<br>not for miner incentives?<br><br>I&#39;m =
asking this because I think a new set of policies should separate<br>polici=
es that address the miner incentives from policies that address<br>the DoS =
issues.<br><br>The two policies I proposed address miner incentives. I thin=
k they&#39;re<br>insufficient to address DoS issues. But adding a 3rd polic=
y to address<br>DoS issues may be a good solution?<br><br>I think that rate=
-limiting p2p as you suggest (and Gloria also mentioned<br>it) is likely a =
better way of fixing the DoS concerns than a descendant<br>rule like BIP 12=
5 rule 5 (which as I mentioned earlier, is problematic<br>because the desce=
ndent set varies from one mempool to another).<br><br>I would like to add a=
 small update to my policy suggestions. The X and Y<br>percentage increase =
should be met for both the ancestor scores AND the<br>transaction in isolat=
ion. Otherwise I could replace txA with txA&#39; that<br>uses a new ancesto=
r txB that has a high fee and high feerate, while txA&#39;<br>has a low fee=
 and low feerate. It&#39;s then possible for txB to confirm<br>without txA&=
#39;, and what would remain then in the mempool would be worse<br>than befo=
re the replacement.<br><br>&gt; All you need is for there to be *a* path th=
at follows the new relay rules<br>&gt; and gets from your node/wallet to pe=
rhaps 10% of hashpower, which seems<br>&gt; like something wallet providers=
 could construct relatively quickly?<br><br>That&#39;s true, maybe we can b=
e more optimistic about the timeline for<br>using an updated set of policie=
s ;)<br><br>&gt; Do you think such multi party contracts are vulnerable by =
design<br>&gt; considering they rely on policy that cannot be enforced?<br>=
<br>It&#39;s a good question. Even though these policies cannot be enforced=
, if<br>they are rational to apply by nodes, I think it&#39;s ok to rely on=
 them.<br>Others may disagree with that, but I guess it&#39;s worth a separ=
ate thread.<br><br>&gt; Not sure I understand this part because if a transa=
ction is on-chain<br>&gt; it can&#39;t be replaced.<br><br>Sorry, that was =
a bit unclear.<br><br>Suppose I have txA that I want to RBF, but I only hav=
e unconfirmed utxos<br>and I can&#39;t simply lower its existing outputs to=
 reach my desired<br>feerate.<br><br>I must make one of my unconfirmed utxo=
s confirm asap just to be able to<br>use it to RBF txA. That means I&#39;ll=
 need to pay fees a first time just to<br>convert one of my unconfirmed utx=
os to a confirmed one. Then I&#39;ll pay<br>the fees to bump txA. I had to =
overpay fees compared to just using my<br>unconfirmed utxo in the first pla=
ce (and manage more complexity to track<br>the confirmation of my unconfirm=
ed utxo).<br><br>Thanks for your feedback!<br>Bastien</div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mar. 1 f=C3=
=A9vr. 2022 =C3=A0=C2=A003:47, Prayank &lt;<a href=3D"mailto:prayank@tutano=
ta.de">prayank@tutanota.de</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div>
<div>Hi Bastein,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt=
; This work will highly improve the security of any multi-party contract tr=
ying to build on top of bitcoin</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Do you think such multi party contracts are vulnerable by design =
considering they rely on policy that cannot be enforced?<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">&gt; For starters, let me quickly exp=
lain why the current rules are hard to work with in the context of lightnin=
g</div><div dir=3D"auto"><br></div><div dir=3D"auto">Using the term &#39;ru=
les&#39; can be confusing sometimes because it&#39;s just a policy and diff=
erent from consensus rules. I wish we could change this in the BIP with som=
ething else.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; I&=
#39;m actually paying a high fee twice instead of once (and needlessly usin=
g on-chain space, our scarcest asset, because we could have avoided that ad=
ditional transaction</div><div dir=3D"auto"><br></div><div dir=3D"auto">Not=
 sure I understand this part because if a transaction is on-chain it can&#3=
9;t be replaced.=C2=A0<br></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">&gt; The second biggest pain point is rule 3. It prevents me from effici=
ently using my capital while it&#39;s unconfirmed</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">&gt; I&#39;m curious to hear other people&#39;s t=
houghts on that. If it makes sense, I would propose the following very simp=
le rules</div><div dir=3D"auto"><br></div><div dir=3D"auto">Looks interesti=
ng however not sure about X and Y.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto"><br></div><div>-- <br></div><div>Prayank<br></div><div><br></div=
><div dir=3D"auto">A3B1 E430 2298 178F<br></div>  </div>

</blockquote></div>

--000000000000f1dd0405d6f18cc5--