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"
Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
Precedence: list

--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--