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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
