email at yancy.lol [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-09 📝 Original message:> technically, all we need ...
📅 Original date posted:2022-11-09
📝 Original message:> 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 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 [1 [1]]
> _______________________________________________
> 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
Links:
------
[1] http://petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1] http://petertodd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221109/62cc0003/attachment-0001.html>;
📝 Original message:> 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 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 [1 [1]]
> _______________________________________________
> 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
Links:
------
[1] http://petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Links:
------
[1] http://petertodd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221109/62cc0003/attachment-0001.html>;