Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 19728C0051 for ; Sat, 19 Sep 2020 16:31:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0104B86B4E for ; Sat, 19 Sep 2020 16:31:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCm7YHggwpHb for ; Sat, 19 Sep 2020 16:31:10 +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 fraxinus.osuosl.org (Postfix) with ESMTPS id 1E307860DE for ; Sat, 19 Sep 2020 16:31:10 +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 08JGV7m9031570 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 19 Sep 2020 12:31:08 -0400 Received: by mail-ej1-f50.google.com with SMTP id u21so12182073eja.2 for ; Sat, 19 Sep 2020 09:31:08 -0700 (PDT) X-Gm-Message-State: AOAM533YNAcGJ6aY7wfDDwG/QGXIVJepsN+VvhARv0so7oKTYTVM+73m XR1yOIyRbSyshj04gMdRgoKMZLUtqTcwGINDH5c= X-Google-Smtp-Source: ABdhPJz8zRP6JMkLglebkWdub23yGrYbRJuD2vfnSz60Nhhl7grjQVNMlOduy8/lXgN9OiKvPC2bHWAL7XIy9TvJdK0= X-Received: by 2002:a17:906:6007:: with SMTP id o7mr43483421ejj.550.1600533067307; Sat, 19 Sep 2020 09:31:07 -0700 (PDT) MIME-Version: 1.0 References: <20200919133716.d5ofags2tprlvpqm@ganymede> In-Reply-To: <20200919133716.d5ofags2tprlvpqm@ganymede> From: Jeremy Date: Sat, 19 Sep 2020 09:30:56 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="000000000000ed9f9005afad246a" 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: Sat, 19 Sep 2020 16:31:11 -0000 --000000000000ed9f9005afad246a Content-Type: text/plain; charset="UTF-8" Hi David! Thanks for taking a look, and great question. > Is this in the reference implementation? It is indeed in the reference implementation. Please see https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx#diff-24efdb00bfbe56b140fb006b562cc70bR741-R743 There is no requirement that there be any input in common, just that the sponsor vectors are identical (keep in mind that we limit our sponsor vector by policy to 1 element, because, as you rightfully point out, multiple sponsors is more complex to implement). > In the second case, I think Mallory can use an existing pinning > technique to make it expensive for Bob to fee bump. The normal > replacement policies require a replacement to pay an absolute higher fee > than the original transaction, so Mallory can create a 100,000 vbyte > transaction with a single-vector sponsor at the end pointing to Bob's > transaction. This sponsor transaction pays the same feerate as Bob's > transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee. In order > for Bob to replace Mallory's sponsor transaction with his own sponsor > transaction, Bob needs to pay the incremental relay feerate (10 > nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC). Yup, I was aware of this limitation but I'm not sure how practical it is as an attack because it's quite expensive for the attacker. But there are a few simple policies that can eliminate it: 1) A Sponsoring TX never needs to be more than, say, 2 inputs and 2 outputs. Restricting this via policy would help, or more flexibly limiting the total size of a sponsoring paying transaction to 1000 bytes. 2) Make A Sponsoring TX not need to pay more absolute fee, just needs to increase the feerate (perhaps with a constant relay fee bump to prevent spam). I think 1) is simpler and should allow full use of the sponsor mechanism while preventing this class of issue mostly. What do you think? --000000000000ed9f9005afad246a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David= !

Thanks for taking a look, and great question.

> Is this in the reference implementation? =

It is indeed in the reference implementation. Please see https://github.com/bitc= oin/bitcoin/compare/master...JeremyRubin:subsidy-tx#diff-24efdb00bfbe56b140= fb006b562cc70bR741-R743

There is no requirement that there be any= input in common, just that the sponsor vectors are identical (keep in mind= that we limit our sponsor vector by policy to 1 element, because, as you r= ightfully point out, multiple sponsors is more complex to implement).
=

=C2=A0
> In the secon= d case, I think Mallory can use an existing pinning
> technique to ma= ke it expensive for Bob to fee bump.=C2=A0 The normal
> replacement p= olicies require a replacement to pay an absolute higher fee
> than th= e original transaction, so Mallory can create a 100,000 vbyte
> trans= action with a single-vector sponsor at the end pointing to Bob's
>= ; transaction.=C2=A0 This sponsor transaction pays the same feerate as Bob&= #39;s
> transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fe= e.=C2=A0 In order
> for Bob to replace Mallory's sponsor transact= ion with his own sponsor
> transaction, Bob needs to pay the incremen= tal relay feerate (10
> nBTC/vbyte) more, so 6 mBTC total ($66 at $11= k/BTC).

= Yup, I was aware of this limitation but I'm not sure how practical it i= s as an attack because it's quite expensive for the attacker. But there= are a few simple policies that can eliminate it:

1) A Sponsori= ng TX never needs to be more than, say, 2 inputs and 2 outputs. Restricting= this via policy would help, or more flexibly limiting the total size of a = sponsoring paying transaction to 1000 bytes.
2) Make A Sponsoring TX not need to pay more absolute fee, j= ust needs to increase the feerate (perhaps with a constant relay fee bump t= o prevent spam).

I think 1) is simpler and should allow full us= e of the sponsor mechanism while preventing this class of issue mostly.

What do you think?

=C2=A0
--000000000000ed9f9005afad246a--