From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 65F88C0051 for ; Tue, 22 Sep 2020 13:53:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 5FCA72000E for ; Tue, 22 Sep 2020 13:53:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvG+VJkxPFTB for ; Tue, 22 Sep 2020 13:53:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by silver.osuosl.org (Postfix) with ESMTPS id 9B22A1FD7D for ; Tue, 22 Sep 2020 13:53:09 +0000 (UTC) Received: by mail-wr1-f45.google.com with SMTP id z4so17172272wrr.4 for ; Tue, 22 Sep 2020 06:53:09 -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 :cc; bh=CoSujKLP3faW1AVJkadnIquk03W7kXhS45+7C0Nnhu0=; b=AV9OSjD0eMQ4aCjXD4+HOxruDV/9dXkW8Qva6EkKiEA6Axh5tFCpBN90kSia3DNItW FZ5AA23xKp2oxWzjk+4vlB3Ynq7gpN39ToY4LAG/Y+ACEhBs/7f5Dp27VUtjL2IarF7M t8g47gRNYzXHo8Kg+JZM+EJ7wzCfzhuYW0SJB6HOjCHY0mj32UM1ja+sbMC6G4gRLhg/ xcRbiGh0EsjJWaK7cBWuAiGlkiLAvSi5LTBu2Nh92sKNvVtVegzaVd7ipdImOZYAx8gB tm/fbLUVE345pKSBY0Onij9uN8x8p7UUACyzJXtPDVlu/C6cuu1HHf0ErgXnv79/rGKV hR7Q== 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:cc; bh=CoSujKLP3faW1AVJkadnIquk03W7kXhS45+7C0Nnhu0=; b=jZ1aorwuSVhPpyhqlthW77MRwYHk7nHGtzcP6xc5eU2OGnHfcEj0E+bqR0O/m9UnMS Kbz2+x/bT0vyoWpHxehyH7qi32Lp10XhfdSN7zbrptvFFnpzYLnWHP5dzUQQ3Ew3+5Gh gdpsY89QhSswnqwCUGZlR+I4NGATNM+YhMUJxeYTm5MSpnuIz+/88/U+p59vNV83K12U NO9SBgr5AyaybckfMqeQVbJ5yJmyQYeOcrfFBJ/KSGqK12O5mT732WaEi3akUgnwjsoo wZnACN6+YP7u2hex62zrvLNRB0QhNUcSBDoWVhmVwxlSWbBNPaBasyDwidPPC0bk5aaY vs5Q== X-Gm-Message-State: AOAM533wcb8XYbmpuUeV3hhr+DmikgtOTijwKWIzb6JZMA2rtRseRrXK QRx31nGcOYGgdeNvixCtjeEhsekETzr5QL5HZz0= X-Google-Smtp-Source: ABdhPJxKvmSE4VX2gsT+Mp7kMmNCmdghCL8eyVhzXpCaU8Z03k+lpV4Q/1+2KOEHp+Jq6OJaO7AYRtoDo4MdcCh71m4= X-Received: by 2002:adf:ffc3:: with SMTP id x3mr4853567wrs.290.1600782787987; Tue, 22 Sep 2020 06:53:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Tue, 22 Sep 2020 09:52:55 -0400 Message-ID: To: ArmchairCryptologist , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000070cb6405afe7498f" X-Mailman-Approved-At: Tue, 22 Sep 2020 14:27:34 +0000 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 13:53:13 -0000 --00000000000070cb6405afe7498f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello AC, Yes that's a real issue. In the context of multi-party protocols, you may pre-signed transactions with the feerate of _today_ and then only going to be broadcast later with a feerate of _tomorrow_. In that case the pre-signed feerate may be so low that the transaction won't even propagate across network mempools with a local minimal feerate higher. That's why you want to be sure that the feerate of your package of transactions (either sponsor+sponsoree or parent+CPFP) is going to be evaluated as a whole to decide acceptance of each element of the package. Antoine Le mar. 22 sept. 2020 =C3=A0 03:28, ArmchairCryptologist via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > Not sure if I'm missing something, but I'm curious if (how) this will wor= k > if the sponsored transaction's feerate is so low that it has been largely > evicted from mempools due to fee pressure, and is too low to be widely > accepted when re-broadcast? It seems to me that the following requirement > > >1. The Sponsor Vector's entry must be present in the mempool > > means that you enter a catch-22 where the sponsor transaction cannot be > broadcast because the sponsored transaction is not in the mempool, and th= e > sponsored transaction cannot be (re-)broadcast because the fee is too low= . > This requirement might therefore need to be revised. > > There is of course no global mempool, but RBF by its nature would still > work in this case, by replacing the transaction if it exists and insertin= g > it if it does not. > > --AC > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000070cb6405afe7498f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello AC,

Yes that's a rea= l issue. In the context of multi-party protocols, you may pre-signed transa= ctions with the feerate of _today_ and then only going to be broadcast late= r with a feerate of _tomorrow_.
In that case the pre-signed feerat= e may be so low that the transaction won't even propagate across networ= k mempools with a local minimal feerate higher.

That'= s why you want to be sure that the feerate of your=C2=A0 package of transac= tions (either sponsor+sponsoree or parent+CPFP) is going to be evaluated as= a whole to decide acceptance of each element of the package.

=
Antoine
=C2=A0

Le=C2=A0mar. 22 sept. 2020 =C3=A0=C2= =A003:28, ArmchairCryptologist via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&= gt; a =C3=A9crit=C2=A0:
Not sure if I'm missing something, but I'm curious if = (how) this will work if the sponsored transaction's feerate is so low t= hat it has been largely evicted from mempools due to fee pressure, and is t= oo low to be widely accepted when re-broadcast? It seems to me that the fol= lowing requirement

>1. The Sponsor Vector&#= 39;s entry must be present in the mempool

mean= s that you enter a catch-22 where the sponsor transaction cannot be broadca= st because the sponsored transaction is not in the mempool, and the sponsor= ed transaction cannot be (re-)broadcast because the fee is too low. This re= quirement might therefore need to be revised.

= There is of course no global mempool, but RBF by its nature would still wor= k in this case, by replacing the transaction if it exists and inserting it = if it does not.

--AC
____________________= ___________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000070cb6405afe7498f--