path: root/d1/4d01237e50fc1a3405f3332bd8f6c0bb195e1d

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6B6E4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Nov 2022 13:32:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 3F4A760A7B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Nov 2022 13:32:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3F4A760A7B
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
 header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=Os2K+fv8
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id lEMFNW9DXDtR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Nov 2022 13:32:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DD141606C0
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com
 [IPv6:2607:f8b0:4864:20::e35])
 by smtp3.osuosl.org (Postfix) with ESMTPS id DD141606C0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Nov 2022 13:32:31 +0000 (UTC)
Received: by mail-vs1-xe35.google.com with SMTP id z189so1886362vsb.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 03 Nov 2022 06:32:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20210112.gappssmtp.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=HY1wD1b/ty6FqBTbca7m1j4Qbv0HNpx1clvVe1WnB8g=;
 b=Os2K+fv80CNgsN4/c2pADpReSa6/r+Bi18pe0DFiOesj9ZGh/OQU1ki3omLL4qDHt6
 RTvcqc32KGQhlFyo8AzaRwJEdzUBKYbcvaN4oSgkJLqjwjpkq3IWqPc90epc71XHn0ks
 hkPZMdspFrigscFvmje75u+7oo6BokzT2/RrnutdbAd/d0i7McqTAfdH5wbXsXHXqEiD
 +uPeJF8z6+lWgxsgtTvq74gUxlX2Q4eC1+yjtmtZC9Zr20C6mJYic3dhZWi3GcMbL8Tx
 O6hqVt5KTwfJeh3AZhu0cuW2QyphRFX28groG/ig/Lkrag15eHA2DbNxGSyw5XlgFTMr
 RNfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=HY1wD1b/ty6FqBTbca7m1j4Qbv0HNpx1clvVe1WnB8g=;
 b=M7wEyB4Yc/zjeLQXQWY2dgA0b9EQ13jq3FQIbZRc93gw38t/ChQFOTXC6Tysj1VLsc
 9ZqudYzBKUBtzSSaCmXltzOYhWrExRtkXmpi8Qv9QkMKAQOeeSzvXESiYSllegQHAXRC
 FxiML+ike4gA9WncZYznb2+HarDg6A1jarxbRsL/szSji1gTfZovqUKcBs0heacS1/r1
 0hA7i0XBp06T0qGrKKxlHL2C35OrPGznqAPcHCxs5S2QoUfPXQuWFoWsAdoffi09N6D/
 eYdgzPABnr/03fXW6vFT32ky1vXB+VMmZroLlUVP0QdhHPQd3QWc/zqbUzk9kJylqr+V
 28sg==
X-Gm-Message-State: ACrzQf0+MTGC28o0FszcY1bfcuw1q/NkRsYr4VtJdJKXIrq8Rr/51/F5
 yZ8+KCuU4hNy8Xl5nXt/sCNWX6nXhniiy1gMD0WVsrkppVx/
X-Google-Smtp-Source: AMsMyM43yfN1Tiymd3brF+qm0QODw+v6LyCEPDvzuDEH+5XyWZWJLpGa4BeCgtTiD8Ssv076XwnxbIsd4ujwImygKEU=
X-Received: by 2002:a05:6102:14aa:b0:3ac:b1ee:5529 with SMTP id
 d42-20020a05610214aa00b003acb1ee5529mr16479120vsv.40.1667482350363; Thu, 03
 Nov 2022 06:32:30 -0700 (PDT)
MIME-Version: 1.0
References: <Y2I3w8O5X55sD/3C@petertodd.org>
 <fMZWicZXp5SM0ON8jgYuykBydOXcbgePbPfGKA0DQYtEDdiIr4bWljL_TqQHKtVKZRhvRXkEab47aaZw17OxGaSgOP2_w9_Owjb9WnTmsQ0=@protonmail.com>
In-Reply-To: <fMZWicZXp5SM0ON8jgYuykBydOXcbgePbPfGKA0DQYtEDdiIr4bWljL_TqQHKtVKZRhvRXkEab47aaZw17OxGaSgOP2_w9_Owjb9WnTmsQ0=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 3 Nov 2022 09:32:20 -0400
Message-ID: <CAJowKgKGsAGQyCmx24fRZWrAWCVi91QKxXaQGiXLJ6zEFXnneg@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000029a9e505ec90fd32"
X-Mailman-Approved-At: Thu, 03 Nov 2022 14:05:19 +0000
Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Thu, 03 Nov 2022 13:32:33 -0000

--00000000000029a9e505ec90fd32
Content-Type: text/plain; charset="UTF-8"

actually, peter makes an important point here

technically, all we need is for *miners* to consistently mine "full rbf"

as long as they do, businesses that accept 0conf will have to adjust their
risk accordingly, and the problem of misaligned incentives is resolved

i don't think it matters what non-mining users do nearly as much


On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Peter,
>
> > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees
> to
> > reward miners that turn on full-RBF. I'm starting small, just
> ~$100/block in
> > times of congestion. Miner and pool profit margins are pretty small, on
> the
> > order of $1k/block in many cases, so I know it doesn't take that much
> more
> > money to make a difference.
>
> I appreciate this effort and perhaps this was all that was needed in
> addition to Bitcoin Core's inclusion of full rbf support. Making it default
> right away or enabling preferential peering with service flag in a bitcoin
> core release was unnecessary.
>
> > If you'd like to donate to this effort, send BTC to
> > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
>
> Sorry, I don't trust you based on some of the things you support on
> Twitter. Hopefully, others will donate and help this bounty.
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > I'm now running a full-RBf bounty program for miners.
> >
> > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees
> to
> > reward miners that turn on full-RBF. I'm starting small, just
> ~$100/block in
> > times of congestion. Miner and pool profit margins are pretty small, on
> the
> > order of $1k/block in many cases, so I know it doesn't take that much
> more
> > money to make a difference.
> >
> > Why should you do this? Full-RBF/zeroconf has been discussed to death.
> But
> > tl;dr: You'll earn more money, and help transition Bitcoin to a more
> secure
> > mempool policy based on economic incentives rather than trust.
> >
> >
> > If you're a miner and want to participate, the easiest way to so is to
> use the
> > mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the
> > 24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots.
> >
> > You can also just modify the code yourself by removing the opt-in RBF
> check.
> > For example against the v23.0 tag:
> >
> > $ git diff
> > diff --git a/src/validation.cpp b/src/validation.cpp
> > index 214112e2b..44c364623 100644
> > --- a/src/validation.cpp
> > +++ b/src/validation.cpp
> > @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args,
> Workspace& ws)
> > // check all unconfirmed ancestors; otherwise an opt-in ancestor
> > // might be replaced, causing removal of this descendant.
> > if (!SignalsOptInRBF(*ptxConflicting)) {
> > - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict");
> > + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict");
> > }
> >
> > ws.m_conflicts.insert(ptxConflicting->GetHash());
> >
> >
> > Once you've enabled full-RBF, you need a full-RBF peer. I'm running a
> few of
> > them:
> >
> > cup.nop.lol
> > mug.nop.lol
> > jar.nop.lol
> > jug.nop.lol
> >
> > These nodes run a preferential peering patch (
> https://github.com/bitcoin/bitcoin/pull/25600)
> > to ensure that full-RBF nodes are interconnected to each other and
> replacements
> > can easily propagate. Also feel free to contact me if you'd like to peer
> with a
> > private node.
> >
> >
> > If you'd like to donate to this effort, send BTC to
> > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
> >
> >
> > ...and yes, I'm well aware that miners could collect this bounty in
> other ways,
> > eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not
> too
> > concerned.
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000029a9e505ec90fd32
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">actually, peter makes an important point here<div><br></di=
v><div>technically, all we need is for *miners* to consistently mine &quot;=
full rbf&quot;</div><div><br></div><div>as long as they do, businesses that=
 accept 0conf=C2=A0will have to adjust their risk accordingly, and the prob=
lem of misaligned incentives is resolved</div><div><br></div><div>i don&#39=
;t think it matters what non-mining users do nearly as much</div><div>=C2=
=A0=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">Hi Peter,<br>
<br>
&gt; tl;dr: I&#39;m broadcasting full-RBF replacements paying extremely hig=
h fees to<br>
&gt; reward miners that turn on full-RBF. I&#39;m starting small, just ~$10=
0/block in<br>
&gt; times of congestion. Miner and pool profit margins are pretty small, o=
n the<br>
&gt; order of $1k/block in many cases, so I know it doesn&#39;t take that m=
uch more<br>
&gt; money to make a difference.<br>
<br>
I appreciate this effort and perhaps this was all that was needed in additi=
on to Bitcoin Core&#39;s inclusion of full rbf support. Making it default r=
ight away or enabling preferential peering with service flag in a bitcoin c=
ore release was unnecessary.<br>
<br>
&gt; If you&#39;d like to donate to this effort, send BTC to<br>
&gt; bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m<br>
<br>
Sorry, I don&#39;t trust you based on some of the things you support on Twi=
tter. Hopefully, others will donate and help this bounty.<br>
<br>
/dev/fd0<br>
<br>
Sent with Proton Mail secure email.<br>
<br>
------- Original Message -------<br>
On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
<br>
&gt; I&#39;m now running a full-RBf bounty program for miners.<br>
&gt; <br>
&gt; tl;dr: I&#39;m broadcasting full-RBF replacements paying extremely hig=
h fees to<br>
&gt; reward miners that turn on full-RBF. I&#39;m starting small, just ~$10=
0/block in<br>
&gt; times of congestion. Miner and pool profit margins are pretty small, o=
n the<br>
&gt; order of $1k/block in many cases, so I know it doesn&#39;t take that m=
uch more<br>
&gt; money to make a difference.<br>
&gt; <br>
&gt; Why should you do this? Full-RBF/zeroconf has been discussed to death.=
 But<br>
&gt; tl;dr: You&#39;ll earn more money, and help transition Bitcoin to a mo=
re secure<br>
&gt; mempool policy based on economic incentives rather than trust.<br>
&gt; <br>
&gt; <br>
&gt; If you&#39;re a miner and want to participate, the easiest way to so i=
s to use the<br>
&gt; mempoolfullrbf=3D1 option in the upcoming Bitcoin Core v24 release (eg=
 the<br>
&gt; 24.0rc3 tag), or use the mempoolreplacement=3Dfee option in Bitcoin Kn=
ots.<br>
&gt; <br>
&gt; You can also just modify the code yourself by removing the opt-in RBF =
check.<br>
&gt; For example against the v23.0 tag:<br>
&gt; <br>
&gt; $ git diff<br>
&gt; diff --git a/src/validation.cpp b/src/validation.cpp<br>
&gt; index 214112e2b..44c364623 100644<br>
&gt; --- a/src/validation.cpp<br>
&gt; +++ b/src/validation.cpp<br>
&gt; @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs&amp; args, =
Workspace&amp; ws)<br>
&gt; // check all unconfirmed ancestors; otherwise an opt-in ancestor<br>
&gt; // might be replaced, causing removal of this descendant.<br>
&gt; if (!SignalsOptInRBF(*ptxConflicting)) {<br>
&gt; - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, &quot;tx=
n-mempool-conflict&quot;);<br>
&gt; + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, &quot=
;txn-mempool-conflict&quot;);<br>
&gt; }<br>
&gt; <br>
&gt; ws.m_conflicts.insert(ptxConflicting-&gt;GetHash());<br>
&gt; <br>
&gt; <br>
&gt; Once you&#39;ve enabled full-RBF, you need a full-RBF peer. I&#39;m ru=
nning a few of<br>
&gt; them:<br>
&gt; <br>
&gt; cup.nop.lol<br>
&gt; mug.nop.lol<br>
&gt; jar.nop.lol<br>
&gt; jug.nop.lol<br>
&gt; <br>
&gt; These nodes run a preferential peering patch (<a href=3D"https://githu=
b.com/bitcoin/bitcoin/pull/25600" rel=3D"noreferrer" target=3D"_blank">http=
s://github.com/bitcoin/bitcoin/pull/25600</a>)<br>
&gt; to ensure that full-RBF nodes are interconnected to each other and rep=
lacements<br>
&gt; can easily propagate. Also feel free to contact me if you&#39;d like t=
o peer with a<br>
&gt; private node.<br>
&gt; <br>
&gt; <br>
&gt; If you&#39;d like to donate to this effort, send BTC to<br>
&gt; bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m<br>
&gt; <br>
&gt; <br>
&gt; ...and yes, I&#39;m well aware that miners could collect this bounty i=
n other ways,<br>
&gt; eg by raising minimum fees. Doing that also breaks zeroconf, so I&#39;=
m not too<br>
&gt; concerned.<br>
&gt; <br>
&gt; --<br>
&gt; <a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank"=
>https://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd=
.org" rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000029a9e505ec90fd32--