Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

From: email@yancy•lol
To: Erik Aronesty <erik@q32•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
Date: Wed, 09 Nov 2022 13:14:52 +0100	[thread overview]
Message-ID: <72fe7342314b5ea419f5c83cc3bc164a@yancy.lol> (raw)
In-Reply-To: <CAJowKgKGsAGQyCmx24fRZWrAWCVi91QKxXaQGiXLJ6zEFXnneg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5046 bytes --]

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

There's another important point I think:

technically, all we need is for *miners* to consistently mine the 
highest fee-rate transaction (or the one with the most incentive).

Miners could probably be incentivized to mine transactions that double 
spend a previous transaction that isn't rbf, also.

Cheers,
-Yancy

On 2022-11-03 14:32, Erik Aronesty via bitcoin-dev wrote:

> 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 [1 [1]]
> _______________________________________________
> 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

Links:
------
[1] http://petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Links:
------
[1] http://petertodd.org

[-- Attachment #2: Type: text/html, Size: 10482 bytes --]