From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B1C19C0051 for ; Mon, 21 Sep 2020 16:27:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 9C8A186685 for ; Mon, 21 Sep 2020 16:27:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tD5ffGg7yUBG for ; Mon, 21 Sep 2020 16:27:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by whitealder.osuosl.org (Postfix) with ESMTPS id 4C197866C4 for ; Mon, 21 Sep 2020 16:27:24 +0000 (UTC) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08LGRLU0014808 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 21 Sep 2020 12:27:22 -0400 Received: by mail-ej1-f50.google.com with SMTP id z22so18575442ejl.7 for ; Mon, 21 Sep 2020 09:27:22 -0700 (PDT) X-Gm-Message-State: AOAM531ACZxIulTn0ucWoqSKu7bcQIHiDqR5Ctg2R/ZU9zF5H//FUK+f TMyPwjjuRpzAEEhgx/8dye8/O3O/4bcYm5zneik= X-Google-Smtp-Source: ABdhPJx5lQGOLHlWEJJBiUNeKMHrx/trJmacGScrLuBO2ho8Wqu/5jv76A+z9WJVCfJ6wLUNez/ASIdp5axRdGf40oc= X-Received: by 2002:a17:906:15c4:: with SMTP id l4mr283178ejd.78.1600705641379; Mon, 21 Sep 2020 09:27:21 -0700 (PDT) MIME-Version: 1.0 References: <20200921145221.76bg5rnw7ohkm3ck@ganymede> In-Reply-To: <20200921145221.76bg5rnw7ohkm3ck@ganymede> From: Jeremy Date: Mon, 21 Sep 2020 09:27:09 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="00000000000024fe7a05afd553d7" Cc: Bitcoin Protocol Discussion 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: Mon, 21 Sep 2020 16:27:26 -0000 --00000000000024fe7a05afd553d7 Content-Type: text/plain; charset="UTF-8" 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.* --00000000000024fe7a05afd553d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 are = likely some cases where you do want TXID and not Output (e.g., if you
<= /b>
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). T= his isn't a concern when the root utxo is multisig & you are a part= icipant.

=
The serialization to support both, w= hile 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 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 sol= ve different but related problems.

Where you migh= t be able to simplify package relay with sponsors is by doing a sponsor-onl= y package relay, which is always limited to 2 transactions, 1 sponsor, 1 sp= onsoree. This would not have some of the challenges with arbitrary-package = package-relay, and would (at least from a ux perspective) allow users to su= ccessfully get parents with insufficient fee into the mempool.




--00000000000024fe7a05afd553d7--