From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 89FD6FA2 for ; Fri, 9 Mar 2018 18:40:40 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 651195E1 for ; Fri, 9 Mar 2018 18:40:39 +0000 (UTC) Date: Fri, 09 Mar 2018 13:40:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1520620836; bh=i8VBm0yHTckSMh7Vk+iohSAxFvhXDDG4oXA80EaybHk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=HQbdRVfrJZE8qKptlSUI+1sd3s9EEzU4/cQh3umkqFihvy7d3mYKSpdNrzk3VVHX5 J0zB+6muiOqttACD8MGHlsvy23D5LfBSeC0mOsgVlXRkb2H9x6sTVuzJS4KXwwA1XM oVBBqqAkEncXISn6llcdCUYasqUdSaucCEXKclQo= To: Peter Todd , Bitcoin Protocol Discussion From: rhavar@protonmail.com Reply-To: rhavar@protonmail.com Message-ID: In-Reply-To: <20180309182803.GE2786@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> <20180212234225.GA9131@fedora-23-dvm> <20180301151129.GA9373@fedora-23-dvm> <20180308183426.GA1093@fedora-23-dvm> <20180309182803.GE2786@fedora-23-dvm> Feedback-ID: RdfuD--Ffc-FNb_4UIG1XA3s5stj1f6Yt84KENdha_3WoiW3STYpu7X5uGR72LvTfQZpxEhSRHGSlNfV5XM5RA==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 09 Mar 2018 20:03:41 +0000 Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 18:40:40 -0000 > Still, re-reading your initital post, I'm convinced that the weakening of= the > DoS protections is probably not a huge problem, so maybe lets try this in= a > release and see what happens. Awesome! I very much agree. The relaxation of some of these DoS prevention = rules I think will really open up a lot of use cases and adoption=20 > Notably, if people actually use this new replacement behavior, the instit= utions > doing these sweeps of unconfirmed outputs might stop doing that!=20 Agree, I'm pretty sure it's unintentional. I know a lot of services struggl= e with coin selection, so what they do is conceptually have a receive walle= t from which they can sweep to their hot wallet (or cold storage) to keep t= heir utxo manageable. Currently some of them are sweeping unconfirmed inputs with it, but I don't= think it's a conscious design choice, just something that happens to be wo= rking well now. (FWIW I observed this behavior like 6+ months ago, I haven't kept track of = if it's still happening or how often. But at the time I had to write off th= e idea of low-fee rbf batch transactions as it was happening too often to b= e feasible) =E2=80=8B-Ryan=E2=80=8B =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On March 9, 2018 1:28 PM, Peter Todd via bitcoin-dev wrote: > =E2=80=8B=E2=80=8B >=20 > On Thu, Mar 08, 2018 at 03:07:43PM -0500, Russell O'Connor wrote: >=20 > > On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd pete@petertodd.org wrote: > >=20 > > > But that's not a good argument: whether or not normal users are tryin= g to > > >=20 > > > attack each other has nothing to do with whether or not you're openin= g up > > >=20 > > > an > > >=20 > > > attack by relaxing anti-DoS protections. > >=20 > > I'm not suggesting removing the anti-DoS protections. I'm suggesting th= at > >=20 > > replaced transaction require a fee increase of at least the min-fee-rat= e > >=20 > > times the size of all the transactions being ejected (in addition to th= e > >=20 > > other proposed requirements). >=20 > Fair: you're not removing them entirely, but you are weakening them compa= red to >=20 > the status quo. >=20 > > > Equally, how often are normal users who aren't attacking each other > > >=20 > > > creating > > >=20 > > > issues anyway? You can always have your wallet code just skip use of = RBF > >=20 > > replacements in the event that someone does spend an unconfirmed output= that > >=20 > > > you sent them; how often does this actually happen in practice? > >=20 > > Just ask rhavar. It happens regularly. > >=20 > > Not many wallets let you spend unconfirmed outputs that you didn't crea= te. > >=20 > > >=20 > >=20 > > The problem is with institutional wallets sweeping incoming payments. I= t > >=20 > > seems that in practice they are happy to sweep unconfirmed outputs. >=20 > Pity, that does sound like a problem. :( >=20 > > Setting all of the above aside for a moment. We need to understand that > >=20 > > rational miners are going to prefer to transactions with higher package= fee > >=20 > > rates regardless of whatever your personal preferred RBF policy is. If = we > >=20 > > do not bring the RBF policy to alignment with what is economically > >=20 > > rational, then miners are going to change their own policies anyways, > >=20 > > probably all in slightly different ways. It behooves everyone to develo= p a > >=20 > > reasonable standard RBF policy, that is still robust against possible D= oS > >=20 > > vectors, and aligns with miner incentives, so that all participants kno= w > >=20 > > what behaviour they can reasonably expect. It is simply a bonus that th= is > >=20 > > change in RBF policy also partially mitigates the problem of pinned > >=20 > > transactions. >=20 > Miners and full nodes have slightly different priorities here; it's not c= lear >=20 > to me why it matters that they implement slightly different policies. >=20 > Still, re-reading your initital post, I'm convinced that the weakening of= the >=20 > DoS protections is probably not a huge problem, so maybe lets try this in= a >=20 > release and see what happens. >=20 > Notably, if people actually use this new replacement behavior, the instit= utions >=20 > doing these sweeps of unconfirmed outputs might stop doing that! That's >=20 > probably a good thing, as respends of potentially conflicted unconfirmed >=20 > outputs can be dangerous in reorgs; we're better off if outputs are burie= d >=20 > deeply before being spent again. >=20 >=20 > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---- >=20 > https://petertodd.org 'peter'\[:-1\]@petertodd.org >=20 > bitcoin-dev mailing list >=20 > bitcoin-dev@lists.linuxfoundation.org >=20 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev