📅 Original date posted:2022-11-03
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221103/4eeed0c1/attachment.html>;
Erik Aronesty [ARCHIVE] /
npub1y2…5taj0
2023-06-07 23:16:29
in reply to nevent1q…wrgu
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-06-07 23:16:29Event JSON
{
"id": "6c7a861ff50b1167aa1a4a970d3f95b9d0fe4b323a9535d8d91e0dc413720799",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686179789,
"kind": 1,
"tags": [
[
"e",
"53863d946949a2ae2f81e8e46cc085f527f0385bf5b23772d3e452c9330a8253",
"",
"root"
],
[
"e",
"0eb589f83d9ed83e40c3efda8590cd4e0fab05f7bbb65f3c704f82fee4883cee",
"",
"reply"
],
[
"p",
"745e2723e72d7ded3f0dd293d710b706cd302ab8476983c292d4bdb7f9c5d366"
]
],
"content": "📅 Original date posted:2022-11-03\n📝 Original message:actually, peter makes an important point here\n\ntechnically, all we need is for *miners* to consistently mine \"full rbf\"\n\nas long as they do, businesses that accept 0conf will have to adjust their\nrisk accordingly, and the problem of misaligned incentives is resolved\n\ni don't think it matters what non-mining users do nearly as much\n\n\nOn Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Peter,\n\u003e\n\u003e \u003e tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees\n\u003e to\n\u003e \u003e reward miners that turn on full-RBF. I'm starting small, just\n\u003e ~$100/block in\n\u003e \u003e times of congestion. Miner and pool profit margins are pretty small, on\n\u003e the\n\u003e \u003e order of $1k/block in many cases, so I know it doesn't take that much\n\u003e more\n\u003e \u003e money to make a difference.\n\u003e\n\u003e I appreciate this effort and perhaps this was all that was needed in\n\u003e addition to Bitcoin Core's inclusion of full rbf support. Making it default\n\u003e right away or enabling preferential peering with service flag in a bitcoin\n\u003e core release was unnecessary.\n\u003e\n\u003e \u003e If you'd like to donate to this effort, send BTC to\n\u003e \u003e bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m\n\u003e\n\u003e Sorry, I don't trust you based on some of the things you support on\n\u003e Twitter. Hopefully, others will donate and help this bounty.\n\u003e\n\u003e /dev/fd0\n\u003e\n\u003e Sent with Proton Mail secure email.\n\u003e\n\u003e ------- Original Message -------\n\u003e On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\n\u003e \u003e I'm now running a full-RBf bounty program for miners.\n\u003e \u003e\n\u003e \u003e tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees\n\u003e to\n\u003e \u003e reward miners that turn on full-RBF. I'm starting small, just\n\u003e ~$100/block in\n\u003e \u003e times of congestion. Miner and pool profit margins are pretty small, on\n\u003e the\n\u003e \u003e order of $1k/block in many cases, so I know it doesn't take that much\n\u003e more\n\u003e \u003e money to make a difference.\n\u003e \u003e\n\u003e \u003e Why should you do this? Full-RBF/zeroconf has been discussed to death.\n\u003e But\n\u003e \u003e tl;dr: You'll earn more money, and help transition Bitcoin to a more\n\u003e secure\n\u003e \u003e mempool policy based on economic incentives rather than trust.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e If you're a miner and want to participate, the easiest way to so is to\n\u003e use the\n\u003e \u003e mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the\n\u003e \u003e 24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots.\n\u003e \u003e\n\u003e \u003e You can also just modify the code yourself by removing the opt-in RBF\n\u003e check.\n\u003e \u003e For example against the v23.0 tag:\n\u003e \u003e\n\u003e \u003e $ git diff\n\u003e \u003e diff --git a/src/validation.cpp b/src/validation.cpp\n\u003e \u003e index 214112e2b..44c364623 100644\n\u003e \u003e --- a/src/validation.cpp\n\u003e \u003e +++ b/src/validation.cpp\n\u003e \u003e @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs\u0026 args,\n\u003e Workspace\u0026 ws)\n\u003e \u003e // check all unconfirmed ancestors; otherwise an opt-in ancestor\n\u003e \u003e // might be replaced, causing removal of this descendant.\n\u003e \u003e if (!SignalsOptInRBF(*ptxConflicting)) {\n\u003e \u003e - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,\n\u003e \"txn-mempool-conflict\");\n\u003e \u003e + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,\n\u003e \"txn-mempool-conflict\");\n\u003e \u003e }\n\u003e \u003e\n\u003e \u003e ws.m_conflicts.insert(ptxConflicting-\u003eGetHash());\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Once you've enabled full-RBF, you need a full-RBF peer. I'm running a\n\u003e few of\n\u003e \u003e them:\n\u003e \u003e\n\u003e \u003e cup.nop.lol\n\u003e \u003e mug.nop.lol\n\u003e \u003e jar.nop.lol\n\u003e \u003e jug.nop.lol\n\u003e \u003e\n\u003e \u003e These nodes run a preferential peering patch (\n\u003e https://github.com/bitcoin/bitcoin/pull/25600)\n\u003e \u003e to ensure that full-RBF nodes are interconnected to each other and\n\u003e replacements\n\u003e \u003e can easily propagate. Also feel free to contact me if you'd like to peer\n\u003e with a\n\u003e \u003e private node.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e If you'd like to donate to this effort, send BTC to\n\u003e \u003e bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e ...and yes, I'm well aware that miners could collect this bounty in\n\u003e other ways,\n\u003e \u003e eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not\n\u003e too\n\u003e \u003e concerned.\n\u003e \u003e\n\u003e \u003e --\n\u003e \u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221103/4eeed0c1/attachment.html\u003e",
"sig": "49141dc55a166c67d0b9ccac369c51bb892a2cb0ced38127f505f1a4a8a6d1512e7cb60ddb57bfd024d79d03a3e247e131d0286ac517a595640fc4768bd8dab4"
}