Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 791C4C000B for ; 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 ; 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 ; 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 ; Tue, 1 Feb 2022 09:30:24 +0000 (UTC) Received: by mail-yb1-xb2c.google.com with SMTP id 23so48894439ybf.7 for ; 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: In-Reply-To: From: Bastien TEINTURIER Date: Tue, 1 Feb 2022 10:30:12 +0100 Message-ID: To: Prayank , Anthony Towns Content-Type: multipart/alternative; boundary="000000000000f1dd0405d6f18cc5" X-Mailman-Approved-At: Tue, 01 Feb 2022 09:35:59 +0000 Cc: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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 wi= ll never get confirmed -- if they were to eventually get confirmed
> = it wouldn't be a waste of bandwith, after all. But if the original
&= gt; 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 m= atter for DoS resistance then,
not for miner incentives?

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

The two policies I proposed address miner incentives. I thin= k they're
insufficient to address DoS issues. But adding a 3rd polic= y 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 12= 5 rule 5 (which as I mentioned earlier, is problematic
because the desce= ndent 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 isolat= ion. Otherwise I could replace txA with txA' that
uses a new ancesto= r 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&= #39;, and what would remain then in the mempool would be worse
than befo= re the replacement.

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

That's true, maybe we can b= e more optimistic about the timeline for
using an updated set of policie= s ;)

> 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 separ= ate thread.

> Not sure I understand this part because if a transa= ction 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 hav= e unconfirmed utxos
and I can't simply lower its existing outputs to= reach my desired
feerate.

I must make one of my unconfirmed utxo= s 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 utx= os 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 pla= ce (and manage more complexity to track
the confirmation of my unconfirm= ed utxo).

Thanks for your feedback!
Bastien

Le=C2=A0mar. 1 f=C3= =A9vr. 2022 =C3=A0=C2=A003:47, Prayank <prayank@tutanota.de> a =C3=A9crit=C2=A0:
=20 =20 =20
Hi Bastein,

>= ; This work will highly improve the security of any multi-party contract tr= ying 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 exp= lain why the current rules are hard to work with in the context of lightnin= g

Using the term 'ru= les' can be confusing sometimes because it's just a policy and diff= erent from consensus rules. I wish we could change this in the BIP with som= ething else.

> 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

Not= sure I understand this part because if a transaction is on-chain it can= 9;t be replaced.=C2=A0

> The second biggest pain point is rule 3. It prevents me from effici= ently using my capital while it's unconfirmed
> I'm curious to hear other people's t= houghts on that. If it makes sense, I would propose the following very simp= le rules

Looks interesti= ng however not sure about X and Y.


--
Prayank

A3B1 E430 2298 178F
--000000000000f1dd0405d6f18cc5--