From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 59813C0051 for ; Tue, 22 Sep 2020 18:05:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 4A23D870AE for ; Tue, 22 Sep 2020 18:05:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iT4040+3cU+S for ; Tue, 22 Sep 2020 18:05:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by hemlock.osuosl.org (Postfix) with ESMTPS id CADDF870AA for ; Tue, 22 Sep 2020 18:05:25 +0000 (UTC) Received: by mail-io1-f43.google.com with SMTP id y13so20658099iow.4 for ; Tue, 22 Sep 2020 11:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LvSZtKMc/4Dud5pVcKeDZQxRcaoXdFwQiaoS/bTmhoU=; b=re5LQBAT17+08keXbdfpszQqdTEYHDmWLurb3kjQoNMaGx9h72BCP156UbH3/N0chu sZ0aCzcHdBBnzRdneYb8BCP1S43xhUDHhAhdB+XvIP16VZ4Tz5RNFceDQQ2+NneUGdgp XTlY+8SUN6+uxnyp02Keu+bZ6gTvLujtCcM34lZUPK97w/WIdAh3IvUk1QsXc4S26V+s YeEdYxv+OmnjBltJURDKYl3hY2rJX0Vgoxne7DXTFM61ejSe43vK4nSjrpf/ceIpt6ju fKi5xkadfLe4y5NKiUMFk9nU7BOTnA702t40BompUU2qJVatTscbgv2R01nARYYKOFOR BSYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=LvSZtKMc/4Dud5pVcKeDZQxRcaoXdFwQiaoS/bTmhoU=; b=qciMbYFbvbxzBKaEO1Uzg8qZlnQOW5v6SLEZ7pxy4XoQtXV79bsDzNHUJjzuFnuq7F IRO551AIGHLML2wVvW2+FULAKuPtjONpilECuiGQ6AeW+zlrnXo5kNe/9uyQFZcdpzX5 attdFfL/JVJfgKxzMMyZIpbN+MvPAGHM89mPpUqTKiQVzRba7rmln9nuYbxbo44iCrk7 lBeyAcj4ROn9TtKVRoHga1cITx4OC932n+jEjr2DYKq5pqOj9wMp7iNzrCr+jw//Wp6Z T4zox5eb+s/Picfgt1XAVRQciKCCcggqPkfq5ZfvRQZd3/DcZkVSFudn8d0tSMSqjHrk Q/vw== X-Gm-Message-State: AOAM531enPnUyvRkusT51BDLSZZgo2NLW9sT9dHE92soF4OHX+h4bqFM ga9TVm4Gv/IZc3pNcPMdDwAXQB8LojnbPeoy0vwmL9e1 X-Google-Smtp-Source: ABdhPJyJneECbmeWz8Wf1iBrnvVMIKnwfdYUpY3SZ236iLLYVJtvWNDnIm3H1ccmc9UXCyRnA6M31KQvgkWeSIX8Ils= X-Received: by 2002:a5d:8b4a:: with SMTP id c10mr4433954iot.143.1600797924427; Tue, 22 Sep 2020 11:05:24 -0700 (PDT) MIME-Version: 1.0 References: <20200921145221.76bg5rnw7ohkm3ck@ganymede> In-Reply-To: From: Suhas Daftuar Date: Tue, 22 Sep 2020 14:05:13 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a48e0905afeacff4" Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive TXID Dependencies for Fee Sponsoring 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, 22 Sep 2020 18:05:27 -0000 --000000000000a48e0905afeacff4 Content-Type: text/plain; charset="UTF-8" Hi, I think the topic of how to improve transaction relay policy and fee bumping is an important one that needs to be worked on, so I'm glad this is a topic of discussion. However I am pretty skeptical of this consensus change proposal: The Sponsor Vector TXIDs must also be in the block the transaction is > validated in, with no restriction on order or on specifying a TXID more > than once. That means that if a transaction is confirmed in a block without its sponsor, the sponsor is no longer valid. This breaks a design principle that has been discussed many times over the years, which is that once a valid transaction is created, it should not become invalid later on unless the inputs are double-spent. This principle has some logical consequences that we've come to accept, such as transaction chains being valid across small reorgs in the absence of malicious (double-spend) behavior. I think that this principle is a useful one and that there should be a high bar for doing away with it. And it seems to me that this proposal doesn't clear that bar -- the fee bumping improvement that this proposal aims at is really coming from the policy change, rather than the consensus change. But if policy changes are the direction we're going to solve these problems, we could instead just propose new policy rules for the existing types of transaction chaining that we have, rather than couple them to a new transaction type. My understanding of the main benefit of this approach is that this allows 3rd parties to participate in fee bumping. But that behavior strikes me as also problematic, because it introduces the possibility of 3rd party griefing, to the extent that sponsor transactions in any way limit chains of transactions that would be otherwise permitted. If Alice sends Bob some coins, and Alice and Bob are both honest and cooperating, Mallory shouldn't be able to interfere with their low-feerate transaction by (eg) pinning it with a large transaction that "sponsors" it (ie a large transaction that is just above the feerate of the parent, which prevents additional child transactions and makes it more expensive to RBF). This last issue of pinning could be improved in this proposal by requiring that a sponsor transaction bring the effective feerate of its package up to something which should be confirmed soon (rather than just being a higher feerate than the tx it is sponsoring). However, we could also carve out a policy rule just like that today, without any consensus changes needed, to help with pinning (which is probably a good idea! I think this would be useful work). So I don't think that approaches in that direction would be unique to this proposal. We allow one Sponsor to replace another subject to normal replacement > policies, they are treated as conflicts. This policy rule of allowing sponsor transactions to RBF each other also seems problematic; that means that if Alice is paying Bob in a transaction that is also sponsoring some other transaction (perhaps from Alice to someone else), then Mallory can cause the transaction going to Bob to become invalid by RBF bumping it and sponsoring the parent transaction herself? Allowing 3rd parties to interfere with transactions between others seems like a complex and undesirable design to introduce. In summary: this proposal seems like a CPFP replacement, requiring many policy rules along with a consensus change to be worked out to get right; I think we could achieve largely the same effect by improving the current policy rules to make CPFP work better without a consensus change. And while what is unique about this proposal is that it allows for 3rd parties to attach themselves to the transaction graph of other parties, I think that is a complex interaction to introduce and has negative side effects as well. On Mon, Sep 21, 2020 at 12:27 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Responses Inline: > > Would it make sense that, instead of sponsor vectors >> pointing to txids, they point to input outpoints? E.g.: >> >> 1. Alice and Bob open a channel with funding transaction 0123...cdef, >> output 0. >> >> 2. After a bunch of state updates, Alice unilaterally broadcasts a >> commitment transaction, which has a minimal fee. >> >> 3. Bob doesn't immediately care whether or not Alice tried to close the >> channel in the latest state---he just wants the commitment >> transaction confirmed so that he either gets his money directly or he >> can send any necessary penalty transactions. So Bob broadcasts a >> sponsor transaction with a vector of 0123...cdef:0 >> >> 4. Miners can include that sponsor transaction in any block that has a >> transaction with an input of 0123...cdef:0. Otherwise the sponsor >> transaction is consensus invalid. >> >> (Note: alternatively, sponsor vectors could point to either txids OR >> input outpoints. This complicates the serialization of the vector but >> seems otherwise fine to me.) >> > > *This seems like a fine suggestion and I think addresses Antoine's issue.* > > > *I think there are likely some cases where you do want TXID and not Output > (e.g., if you * > > *are sponsoring a payment to your locktime'd cold storage wallet (no CPFP) > from an untrusted third party (no RBF), they can grift you into paying for > an unrelated payment). This isn't a concern when the root utxo is multisig > & you are a participant.* > > *The serialization to support both, while slightly more complicated, can > be done in a manner that permits future extensibility as well if there are > other modes people require.* > > > >> >> > If we want to solve the hard cases of pinning, I still think mempool >> > acceptance of a whole package only on the merits of feerate is the >> easiest >> > solution to reason on. >> >> I don't think package relay based only on feerate solves RBF transaction >> pinning (and maybe also doesn't solve ancestor/dependent limit pinning). >> Though, certainly, package relay has the major advantage over this >> proposal (IMO) in that it doesn't require any consensus changes. >> Package relay is also very nice for fixing other protocol rough edges >> that are needed anyway. >> >> -Dave >> > > *I think it's important to keep in mind this is not a rival to package > relay; I think you also want package relay in addition to this, as they > solve different but related problems.* > > > *Where you might be able to simplify package relay with sponsors is by > doing a sponsor-only package relay, which is always limited to 2 > transactions, 1 sponsor, 1 sponsoree. This would not have some of the > challenges with arbitrary-package package-relay, and would (at least from a > ux perspective) allow users to successfully get parents with insufficient > fee into the mempool.* > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000a48e0905afeacff4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hi,
I think the topic of how to improve t=
ransaction relay policy and fee bumping is an important one that needs to b=
e worked on, so I'm glad this is a topic of discussion.  However I am p=
retty skeptical of this consensus change proposal:
The Sponsor Vector TXIDs must also b= e in the block the transaction is validated in, with no restriction on orde= r or on specifying a TXID more than once.

T= hat means that if a transaction is confirmed in a block without its sponsor= , the sponsor is no longer valid.=C2=A0 This breaks a design principle that= has been discussed many times over the years, which is that once a valid t= ransaction is created, it should not become invalid later on unless the inp= uts are double-spent.=C2=A0 This principle has some logical consequences th= at we've come to accept, such as transaction=C2=A0chains being=C2=A0val= id across small reorgs in the absence of malicious (double-spend) behavior.=

I think that this principle is a useful one and t= hat there should be a high bar for doing away with it.=C2=A0 And it seems t= o me that this proposal doesn't clear that bar -- the fee bumping impro= vement that this proposal aims at is really coming from the policy change, = rather than the consensus change. But if policy changes are the direction w= e're going to solve these problems, we could instead just propose new p= olicy rules for the existing types of transaction chaining that we have, ra= ther than couple them to a new transaction type.

M= y understanding of the main benefit of this approach is that this allows 3r= d parties to participate in fee bumping.=C2=A0 But that behavior strikes me= as also problematic, because it introduces the possibility of 3rd party gr= iefing, to the extent that sponsor transactions in any way limit chains of = transactions that would be otherwise permitted.=C2=A0 If Alice sends Bob so= me coins, and Alice and Bob are both honest and cooperating, Mallory should= n't be able to interfere with their low-feerate transaction by (eg) pin= ning it with a large transaction that "sponsors" it (ie a large t= ransaction that is just above the feerate of the parent, which prevents add= itional child transactions and makes it more expensive to RBF).
<= br>
This last issue of pinning could be improved in this proposal= by requiring that a sponsor transaction bring the effective feerate of its= package up to something which should be confirmed soon (rather than just b= eing a higher feerate than the tx it is sponsoring).=C2=A0 However, we coul= d also carve out a policy rule just like that today, without any consensus = changes needed, to help with pinning (which is probably a good idea!=C2=A0 = I think this would be useful work).=C2=A0 So I don't think that approac= hes in that direction would be unique to this proposal.

We allow one Sponso= r to replace another subject to normal replacement policies, they are treat= ed as conflicts.

This policy rule of allowing sp= onsor transactions to RBF each other also seems problematic; that means tha= t if Alice is paying Bob in a transaction that is also sponsoring some othe= r transaction (perhaps from Alice to someone else), then Mallory can cause = the transaction going to Bob to become invalid by RBF bumping it and sponso= ring the parent transaction herself?=C2=A0 Allowing 3rd parties to interfer= e with transactions between others seems like a complex and undesirable des= ign to introduce.

In summary: this proposal seems = like a CPFP replacement, requiring many policy rules along with a consensus= change to be worked out to get right; I think we could achieve largely the= same effect by improving the current policy rules to make CPFP work better= without a consensus change.=C2=A0 And while what is unique about this prop= osal is that it allows for 3rd parties to attach themselves to the transact= ion graph of other parties, I think that is a complex interaction to introd= uce and has negative side effects as well.


On Mon, Sep 21, 2020 at 12:27 PM Jeremy via bitcoin-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:
Responses Inline= :

Would it make sense that, instead of sponsor vectors
pointing to txids, they point to input outpoints?=C2=A0 E.g.:

1. Alice and Bob open a channel with funding transaction 0123...cdef,
=C2=A0 =C2=A0output 0.

2. After a bunch of state updates, Alice unilaterally broadcasts a
=C2=A0 =C2=A0commitment transaction, which has a minimal fee.

3. Bob doesn't immediately care whether or not Alice tried to close the=
=C2=A0 =C2=A0channel in the latest state---he just wants the commitment
=C2=A0 =C2=A0transaction confirmed so that he either gets his money directl= y or he
=C2=A0 =C2=A0can send any necessary penalty transactions.=C2=A0 So Bob broa= dcasts a
=C2=A0 =C2=A0sponsor transaction with a vector of 0123...cdef:0

4. Miners can include that sponsor transaction in any block that has a
=C2=A0 =C2=A0transaction with an input of 0123...cdef:0.=C2=A0 Otherwise th= e sponsor
=C2=A0 =C2=A0transaction is consensus invalid.

(Note: alternatively, sponsor vectors could point to either txids OR
input outpoints.=C2=A0 This complicates the serialization of the vector but=
seems otherwise fine to me.)

This seems like a fine suggestion and I think addresses Antoine's = issue.

I think there a= re likely some cases where you do want TXID and not Output (e.g., if you
are sponsoring a payment to your locktime'd = cold storage wallet (no CPFP) from an untrusted third party (no RBF), they = can grift you into paying for an unrelated payment). This isn't a conce= rn when the root utxo is multisig & you are a participant.

The serialization to support b= oth, while slightly more complicated, can be done in a manner that permits = future extensibility as well if there are other modes people require.

=C2=A0

> If we want to solve the hard cases of pinning, I still think mempool > acceptance of a whole package only on the merits of feerate is the eas= iest
> solution to reason on.

I don't think package relay based only on feerate solves RBF transactio= n
pinning (and maybe also doesn't solve ancestor/dependent limit pinning)= .
Though, certainly, package relay has the major advantage over this
proposal (IMO) in that it doesn't require any consensus changes.
Package relay is also very nice for fixing other protocol rough edges
that are needed anyway.

-Dave

I think it's import= ant to keep in mind this is not a rival to package relay; I think you also = want package relay in addition to this, as they solve different but related= problems.

Where you m= ight be able to simplify package relay with sponsors is by doing a sponsor-= only package relay, which is always limited to 2 transactions, 1 sponsor, 1= sponsoree. This would not have some of the challenges with arbitrary-packa= ge package-relay, and would (at least from a ux perspective) allow users to= successfully get parents with insufficient fee into the mempool.
<= /div>




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