diff options
| author | rhavar <rhavar@protonmail.com> | 2018-03-09 13:40:34 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-03-09 18:40:40 +0000 |
| commit | 681551adf1b3999c14d2327ce64823f0a77d8fd3 (patch) | |
| tree | ff8b9689badc504c889396aab8541aa0cf97795b | |
| parent | ceb38a23466a1e2a58e290db50b21a846ca8d801 (diff) | |
| download | pi-bitcoindev-681551adf1b3999c14d2327ce64823f0a77d8fd3.tar.gz pi-bitcoindev-681551adf1b3999c14d2327ce64823f0a77d8fd3.zip | |
Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
| -rw-r--r-- | 50/4c81bd58970a6e53e17ddc54f14c2115a1bfc3 | 229 |
1 files changed, 229 insertions, 0 deletions
diff --git a/50/4c81bd58970a6e53e17ddc54f14c2115a1bfc3 b/50/4c81bd58970a6e53e17ddc54f14c2115a1bfc3 new file mode 100644 index 000000000..8d3d6704a --- /dev/null +++ b/50/4c81bd58970a6e53e17ddc54f14c2115a1bfc3 @@ -0,0 +1,229 @@ +Return-Path: <rhavar@protonmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 89FD6FA2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <pete@petertodd.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: rhavar@protonmail.com +Reply-To: rhavar@protonmail.com +Message-ID: <ZmiZUf6iUcddY1CKMADBa8FryCgrZ1235R4bHParR8NpwibjA-EY38D_GElA9jv4Z-zPZE9juQKgJjpd4MFfjg9ySFvO51dOHNoObHdaLjo=@protonmail.com> +In-Reply-To: <20180309182803.GE2786@fedora-23-dvm> +References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com> + <20180212225828.GB8551@fedora-23-dvm> + <CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com> + <20180212234225.GA9131@fedora-23-dvm> + <CAMZUoK=Htds5fu5vnqAhEoZDrwHALKe6uwqXnmJb17pa_peFFw@mail.gmail.com> + <20180301151129.GA9373@fedora-23-dvm> + <CAMZUoKkG8tbdb+6tGmpvgXb-=3Tu4JsTWXz77o3EC+4Bcbd17A@mail.gmail.com> + <20180308183426.GA1093@fedora-23-dvm> + <CAMZUoKkDnJv33H-DveHtwpnyALS5LoX-OAnabJyvPo4c1DBJRQ@mail.gmail.com> + <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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@lists.lin= +uxfoundation.org> 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 + + + |