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 1F1F6C0051 for ; Sat, 19 Sep 2020 15:01:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 12685867E3 for ; Sat, 19 Sep 2020 15:01:22 +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 Uai5j241plac for ; Sat, 19 Sep 2020 15:01:21 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by whitealder.osuosl.org (Postfix) with ESMTPS id D574882504 for ; Sat, 19 Sep 2020 15:01:20 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id w11so9335118lfn.2 for ; Sat, 19 Sep 2020 08:01:20 -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=5feZFeh/b4gIhU4rFLnbMYyow00L48FaJJL2Mg6982E=; b=UYLLASOOkZx+/FL0xu5YE6HKs9Xa1ujAMlhPYRdSbboumEuCxlLGrLEpgpNkdREdlF GW2pHG03Sd6+NVtAHH8Y9twWNWUsVb377llUWf6pDqqAYtEiG0Ndpm2GgJLA8h9H06Oa sGcZnApVm24tDq/Qj5Mu/og0okBUbKRgqisij1jrhmxlHzz7B/BfX7KckhDznq8VRDTJ X2Yfu1m9HDOKYJq3TtyGpDP6KojIVUhyspg4UfHmd0dvssWYvNHEtIetbVrFzOmvIyEi OlJiRiVQRH3AsZ53otgy8wR9L2tPy4gda0o1W91eSWtECxECs+d4FtLhs4nnIqmDP0u4 /oAw== 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=5feZFeh/b4gIhU4rFLnbMYyow00L48FaJJL2Mg6982E=; b=pzvD2xQH+CYoUVCmbceInjutKYbG/80BosPxs+W4NTCR4hGcv6HbTvC+UXJ5QtIzU9 yw7fONDw9fTT0P7F3kQYVnsyun5Cpf+dyT6bT7VyBrsXSWyJ4xFZ9m6KQvQsd5xfq4Dt hYaiaN4m4CG7fl9r+aPkE6v/JjZ6ny4erqnRqLNfNm3ZYq8oOHm/e+3t/Xfu6lY6tB6Z KptswCewnff2Ek/edNVNCTIWPeIyUGIFOZYPgLfA47h8ziGuMOuTP2NG00jJpLjHRBvV jkbDz00lQUj8xrlT2Chfrv2h3vLc7cK7ClDW6rDDtHdpX91/mUbq3X19ptUrhD88I7rR nKJA== X-Gm-Message-State: AOAM532BbA8xfugSBS+UsfS0Ub7fnPgm83Dt1/1W/26D1nXjC3xrk63N ifKSA1VNJL4z5cidotsxLNO7U3H93cMwwbZQoSY= X-Google-Smtp-Source: ABdhPJzpYoGs+TARqZvNhMUcW42pq/gCaqxeJzlH2KCmH05FRbQjwJK0bmJxDWm0BxwmV898rUP17ZSsGHBjyLfxcGg= X-Received: by 2002:ac2:4c19:: with SMTP id t25mr11762656lfq.375.1600527678851; Sat, 19 Sep 2020 08:01:18 -0700 (PDT) MIME-Version: 1.0 References: <20200919133716.d5ofags2tprlvpqm@ganymede> In-Reply-To: <20200919133716.d5ofags2tprlvpqm@ganymede> From: nopara73 Date: Sat, 19 Sep 2020 17:01:07 +0200 Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c04f7605afabe364" X-Mailman-Approved-At: Sat, 19 Sep 2020 15:04:23 +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: Sat, 19 Sep 2020 15:01:22 -0000 --000000000000c04f7605afabe364 Content-Type: text/plain; charset="UTF-8" Wouldn't this enable a passive adversary listening the mempool to associate unrelated TXO clusters to the same user? On Sat, Sep 19, 2020, 15:38 David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev wrote: > > I'd like to share with you a draft proposal for a mechanism to replace > > CPFP and RBF for increasing fees on transactions in the mempool that > > should be more robust against attacks. > > Interesting idea! This is going to take a while to think about, but I > have one immediate question: > > > To prevent garbage sponsors, we also require that: > > > > 1. The Sponsor's feerate must be greater than the Sponsored's ancestor > fee rate > > > > We allow one Sponsor to replace another subject to normal replacement > > policies, they are treated as conflicts. > > Is this in the reference implementation? I don't see it and I'm > confused by this text. I think it could mean either: > > 1. Sponsor Tx A can be replaced by Sponsor Tx B if A and B have at least > one input in common (which is part of the "normal replacement policies") > > 2. A can be replaced by B even if they don't have any inputs in common > as long as they do have a Sponsor Vector in common (while otherwise > using the "normal replacement policies"). > > In the first case, I think Mallory can prevent Bob from > sponsor-fee-bumping (sponsor-bumping?) his transaction by submitting a > sponsor before he does; since Bob has no control over Mallory's inputs, > he can't replace Mallory's sponsor tx. > > 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). > > Thanks, > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000c04f7605afabe364 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wouldn't this enable a passive adversary listening th= e mempool to associate unrelated TXO clusters to the same user?

On Sat, Sep = 19, 2020, 15:38 David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Fri, Sep 18, 2020 a= t 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:
> I'd like to share with you a draft proposal for a mechanism to rep= lace
> CPFP and RBF for increasing fees on transactions in the mempool that > should be more robust against attacks.

Interesting idea!=C2=A0 This is going to take a while to think about, but I=
have one immediate question:

> To prevent garbage sponsors, we also require that:
>
> 1. The Sponsor's feerate must be greater than the Sponsored's = ancestor fee rate
>
> We allow one Sponsor to replace another subject to normal replacement<= br> > policies, they are treated as conflicts.

Is this in the reference implementation?=C2=A0 I don't see it and I'= ;m
confused by this text.=C2=A0 I think it could mean either:

1. Sponsor Tx A can be replaced by Sponsor Tx B if A and B have at least =C2=A0 =C2=A0one input in common (which is part of the "normal replace= ment policies")

2. A can be replaced by B even if they don't have any inputs in common<= br> =C2=A0 =C2=A0as long as they do have a Sponsor Vector in common (while othe= rwise
=C2=A0 =C2=A0using the "normal replacement policies").

In the first case, I think Mallory can prevent Bob from
sponsor-fee-bumping (sponsor-bumping?) his transaction by submitting a
sponsor before he does; since Bob has no control over Mallory's inputs,=
he can't replace Mallory's sponsor tx.

In the second case, I think Mallory can use an existing pinning
technique to make it expensive for Bob to fee bump.=C2=A0 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.=C2=A0 This sponsor transaction pays the same feerate as Bob= 9;s
transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee.=C2=A0 In or= der
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).

Thanks,

-Dave
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000c04f7605afabe364--