Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2B4AEC002D for ; Wed, 9 Nov 2022 12:14:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id EA8474035D for ; Wed, 9 Nov 2022 12:14:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EA8474035D X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1oikoWwNRbK for ; Wed, 9 Nov 2022 12:14:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1D21D4028D Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by smtp2.osuosl.org (Postfix) with ESMTPS id 1D21D4028D for ; Wed, 9 Nov 2022 12:14:55 +0000 (UTC) Received: (Authenticated sender: email@yancy.lol) by mail.gandi.net (Postfix) with ESMTPA id DBEDB1BF20D; Wed, 9 Nov 2022 12:14:52 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 09 Nov 2022 13:14:52 +0100 From: email@yancy.lol To: Erik Aronesty , Bitcoin Protocol Discussion In-Reply-To: References: Message-ID: <72fe7342314b5ea419f5c83cc3bc164a@yancy.lol> X-Sender: email@yancy.lol Content-Type: multipart/alternative; boundary="=_a423313e4beb0aef66b9c1dab28dea4f" X-Mailman-Approved-At: Wed, 09 Nov 2022 13:02:06 +0000 Subject: Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2022 12:14:58 -0000 --=_a423313e4beb0aef66b9c1dab28dea4f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed > 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 > 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 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 --=_a423313e4beb0aef66b9c1dab28dea4f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
= technically, all we need is for *miners* to consistently mine "full
rb= f"
=  
= There's another important point I think:
=  
= technically, all we need is for *miners* to consistently mine the highest f= ee-rate transaction (or the one with the most incentive).
=  
= Miners could probably be incentivized to mine transactions that double spen= d 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 incen= tives 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 e= xtremely
high fees to
reward miners that turn on full-RBF. I'm starting smal= l, 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<= br />addition to Bitcoin Core's inclusion of full rbf support. Making itdefault right away or enabling preferential peering with service
fl= ag in a bitcoin core release was unnecessary.

If you'd like to donate to this effort, send BTC tobc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m

Sorry, I don't trust you based on some of the things you support onTwitter. 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.<= br />
tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
reward miners that turn on full-RBF. I'm starting smal= l, 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 Bit= coin to a
more secure
mempool policy based on economic incentives rather tha= n trust.


If you're a miner and want to participate, the ea= siest way to so
is to use the
mempoolfullrbf=3D1 option in the upcoming Bitcoin Core= v24 release
(eg the
24.0rc3 tag), or use the mempoolreplacement=3Dfee opti= on in Bitcoin
Knots.

You can also just modify the code yourself by re= moving the opt-in
RBF check.
For example against the v23.0 tag:

$ git di= ff
diff --git a/src/validation.cpp b/src/validation.cpp
index 214= 112e2b..44c364623 100644
--- a/src/validation.cpp
+++ b/src/valid= ation.cpp
@@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs&a= mp; args,
Workspace& ws)
// check all unconfirmed ancestors; otherwise an opt-i= n ancestor
// might be replaced, causing removal of this descendant.if (!SignalsOptInRBF(*ptxConflicting)) {
- return state.Invalid(Tx= ValidationResult::TX_MEMPOOL_POLICY,
"txn-mempool-conflict");
+ // return state.Invalid(TxValidationResult::TX_MEMPO= OL_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= =2Enop.lol
jug.nop.lol

These nodes run a preferential peeri= ng patch
(https://github.com/bitcoin/bitcoin/pull/25600= )
to ensure that full-RBF nodes are interconnected to ea= ch 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
bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9= m


...and yes, I'm well aware that miners could collect thi= s bounty
in other ways,
eg by raising minimum fees. Doing that also breaks zer= oconf, so
I'm not too
concerned.

--
https://petertodd.o= rg 'peter'[:-1]@petertodd.org [1]
_______________________= ________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation= =2Eorg
https://lists= =2Elinuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing li= st
bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /blockquote>  

Links:
------
[1] http://petertodd.org<= br />_______________________________________________
bitcoin-dev maili= ng list
bitco= in-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=
--=_a423313e4beb0aef66b9c1dab28dea4f--